Types  for  Lexically-Scoped  Access  Control 


Tachio  Terauchi  Alex  Aiken  Jeffrey  S.  Foster 


Report  No.  UCB/CSD-3-1282 

October  2003 

Computer  Science  Division  (DECS) 
University  of  California 
Berkeley,  California  94720 


Report  Documentation  Page 


Form  Approved 
0MB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number. 


1.  REPORT  DATE 

OCT  2003 


2.  REPORT  TYPE 


4.  TITLE  AND  SUBTITLE 

Types  for  Lexically-Scoped  Access  Control 


6.  AUTHOR(S) 


7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

University  of  California  at  Berkeley, Department  of  Electrical 
Engineering  and  Computer  Sciences, Berkeley, CA, 94720 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 


3.  DATES  COVERED 

00-00-2003  to  00-00-2003 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

We  develop  a  new  system  for  de  ning  and  enforcing  access  control  statically.  In  our  system,  key-pairs 
guard  access  to  resources,  and  the  association  between  key-pairs  and  resources  can  be  changed  at  any 
program  point  (i.e.,  the  binding  is  late).  Our  static  system  uses  an  ordering  on  lexically  scoped  abstract 
names  to  allow  local  access  control  policies  to  be  enforced  in  other  parts  of  a  program.  In  particular  this 
means  that  individual  program  components  can  locally  re  ne  access  control  policies  and  the  policies  will  be 
respected  by  the  entire  program.  The  result  is  a  system  that  can  enforce,  at  compile  time,  a  wide  variety  of 
useful,  ne-grain  access  control  patterns. 

15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 

18.  NUMBER 

19a.  NAME  OE 

ABSTRACT 

OF  PAGES 

RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Same  as 
Report  (SAR) 

34 

Standard  Form  298  (Rev.  8-98} 

Prescribed  by  ANSI  Std  Z39-18 


Types  for  Lexically-Scoped  Access  Control  * 


Tachio  Terauchi  Jeffrey  S.  Foster  Alex  Aiken 

October  15,  2003 


Abstract 

We  develop  a  new  system  for  defining  and  enforcing  access  control  statically.  In  our  system,  key-pairs 
guard  access  to  resources,  and  the  association  between  key-pairs  and  resources  can  be  changed  at  any 
program  point  (i.e.,  the  binding  is  late).  Our  static  system  uses  an  ordering  on  lexically  scoped  abstract 
names  to  allow  local  access  control  policies  to  be  enforced  in  other  parts  of  a  program.  In  particular, 
this  means  that  individual  program  components  can  locally  refine  access  control  policies  and  the  policies 
will  be  respected  by  the  entire  program.  The  result  is  a  system  that  can  enforce,  at  compile  time,  a  wide 
variety  of  useful,  fine-grain  access  control  patterns. 


1  Introduction 

In  situations  where  a  program  P  interacts  with  one  or  more  untrusted  program  components  U,  a  well-specified 
access  control  policy  protects  P’s  resources  from  unwanted  operations  performed  by  U. 

Systems  such  as  Java  and  the  Common  Language  Runtime  (CLR)  provide  a  mechanism  for  defining  and 
enforcing  fine-grain  access  control.  In  these  systems,  a  programmer  defines  permissions  denoting  resources 
that  pieces  of  code  are  allowed  to  access.  For  example,  a  Java  class  that  conducts  network  transactions  needs 
permission  to  access  network  sockets.  A  key  part  of  stack-based  access  control  is  ensuring  that  if  component 
C  does  not  have  permission  to  access  resource  v,  then  C  cannot  gain  access  to  v  by  calling  a  function  that 
has  permission  to  access  v.  To  enforce  stack-based  access  control  policies,  the  run-time  system  records  the 
set  of  permissions  Si,S2,  -  ■  ■  of  each  codes  /i,  A, ...  on  the  execution  stack.  When  a  resource  v  is  accessed, 
the  run-time  system  permits  the  access  only  if  u  €  Hi  That  is,  v  can  be  used  only  if  all  functions  on  the 
stack  have  permission  to  access  v.  Stack-based  access  control  systems  usually  also  include  a  mechanism  for 
gaining  privileges,  so  that  only  a  suffix  of  the  stack  is  examined  for  access  right. 

In  addition  to  a  set  of  pre-defined  permissions,  Java  and  the  CLR  allow  programmers  to  define  new 
permissions.  For  example,  in  an  airline  ticketing  program,  a  flight  scheduling  component  may  define  new 
permissions  used  to  protect  internal  resources  such  as  flight  time  information  from  being  modified  by  a 
ticketing  agent  component. 

This  paper  presents  a  new  stack-based  access  control  system  that  is  enforced  statically,  in  contrast  to  the 
run-time  enforcement  in  Java  and  the  CLR.  We  begin  with  an  example  application  of  our  system,  slightly 
simplified  for  the  purposes  of  introduction.  Before  giving  the  example,  we  give  a  very  compressed  overview 
of  our  approach. 

In  our  system,  permissions  are  expressed  as  key-pairs  consisting  of  a  grant  key  and  a  limit  key.  Each 
key-pair  is  associated  with  a  set  of  resources,  but  the  two  keys  are  used  for  different  operations  on  those 
resources.  We  have  already  mentioned  that  in  stack-based  access  control  each  piece  of  code  may  limit  access 
to  a  set  of  resources;  this  is  the  function  of  limit  keys.  The  power  to  limit  access  is  not  sufficient,  however. 
Something  must  also  grant  access  to  resources,  at  least  initially,  or  no  resources  could  ever  be  used;  this  is  the 
function  of  grant  keys.  Splitting  the  management  of  access  rights  for  a  set  of  resources  into  grant  and  limit 
keys  is  fundamental  to  our  design  and,  we  believe,  gives  our  system  practical  advantages  (see  Section  2). 

*This  research  was  supported  in  part  by  Subcontract  no.  PY-1099  to  Stanford,  Dept,  of  the  Air  Force  prime  contract  no. 
F33615-00-C-1693. 
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A  second  novel  feature  of  our  system  is  subkeys.  Subkeys  are  analogous  to  subclasses  in  an  object-oriented 
language.  If  a  limit  (grant)  key  fci  is  a  subkey  of  a  limit  (grant)  key  ^2  then  ki  guards  access  to  a  subset  of 
the  resources  k2  protects  (see  Section  2.5). 

Finally,  in  our  approach  the  programmer  writes  code  to  expresses  access  control  policies  using  the  fol¬ 
lowing  expressions  for  manipulating  keys  and  resources: 

•  newkey  generates  a  new  pair  of  keys;  newkey  <  p  generates  new  subkeys  of  the  key-pair  p.  Initially, 
keys  are  not  associated  with  any  resources. 

•  associate  ei  with  62  associates  the  key-pair  ei  with  the  resource  62- 

•  limit  ei  in  62  limits  62 ’s  access  rights  to  the  resources  associated  with  the  limit  key  ei. 

•  grant  ei  in  62  grants  62  access  rights  to  the  resources  associated  with  the  grant  key  ei. 

•  The  function  gKey(p)  (resp.  IKey(p))  returns  the  grant  (resp.  limit)  key  of  the  key  pair  p. 

Consider  two  components  C  and  D  that  need  to  share  access  to  a  number  of  files.  This  is  expressed  in  our 
system  by  creating  a  key-pair,  associating  it  with  the  files,  and  then  granting  access  to  those  files  to  both  C 
and  D: 


sharedjfiles  =  newkey; 

...associate  file_a  with  sharedjfiles; 

...associate  filed)  with  sharedjfiles; 

[Component  C] : 

grcuit  gKey (sharedjfiles)  in 

.../*  accesses  the  shared  files  */ 

[Component  D]  : 

grant  gKey (sharedjfiles)  in 

.../*  accesses  the  shared  files  */ 

Now  assume  that  we  wish  to  add  to  C  a  function  f  that  is  visible  to  other,  less  trusted,  components, 
which  may  or  may  not  have  access  to  sharedjfiles.  We  want  only  certain  files  in  sharedTiles  to  be 
accessible  through  f .  Our  system  is  designed  to  support  such  refinements  of  access  control  policies  with  only 
local  modifications  to  component  C;  in  particular,  neither  component  D  nor  any  other  component  needs  to  be 
modified  to  implement  these  changes.  We  create  a  subkey-pair  some jf lies  of  sharedjfiles  and  associate 
it  with  a  subset  of  files,  say  just  file_a  and  fileJo.  Using  limit,  we  ensure  that  callers  of  the  function 
f  can  access  at  most  the  files  associated  with  somejfiles;  which  files  they  can  actually  access  depends  on 
their  access  rights  at  the  point  where  they  call  f . 

[Component  C] : 

graint  gKey  (sharedjfiles)  in 

somejfiles  =  newkey < sharedjfiles; 

...associate  file_a  with  somejfiles; 

...associate  filej)  with  somejfiles; 

f  =  Ax. limit  IKey (some jf iles)  in 

.../*  accesses  the  selected  files  */ 

Component  D  can  call  f  because  it  has  access  to  sharedjfiles.  But  components  without  access  to  the 
selected  files  cannot. 

In  our  view,  our  system  provides  two  key  features:  late  binding  of  keys  and  resources  (i.e.,  a  resource  can 
be  associated  with  a  key  after  both  the  key  and  the  resource  exist)  and  the  ability  to  create  subkeys  at  any 
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point.  As  a  result,  these  features  allow  late,  local  refinement  of  access  control  policies,  as  well  as  non-local 
enforcement  of  policies.  In  the  example  above,  we  have  added  a  refinement  of  the  original  policy  to  function 
f  in  component  C.  This  policy  is  local  to  C,  meaning  that  the  entire  refinement  is  done  in  the  component  C, 
but  it  is  enforced  non-locally;  i.e.,  a  call  to  f  in  D  respects  the  refined  access  control  policy. 

Our  aim  is  to  statically  check  such  fine-grain  access  control  policies.  There  are  two  benefits  to  static 
access  control.  One  benefit  is  that  it  can  find  access  violations  early  at  compile  time.  The  other  benefit  is 
efficiency;  the  run-time  system  need  not  to  check  for  access  violations. 

Static  checking  requires  our  system  to  statically  track  three  things:  (a)  the  association  between  resources 
and  keys;  (b)  the  subkey  hierarchy;  and  (c)  which  resources  are  used  by  expressions.  For  (a),  we  use  abstract 
names,  which  are  lexically  scoped,  to  identify  keys  and  to  qualify  resource  types  with  their  associated  keys. 
It  is  important  to  note  that  only  the  static  names  of  keys  are  lexically  scoped;  keys  themselves  are  not 
lexically  scoped  and  in  fact  can  be  passed  as  arguments,  stored  in  data  structures,  etc.  For  (b),  the  static 
system  tracks  the  subnaming  hierarchy,  which  is  the  static  analog  of  the  subkey  hierarchy.  Finally,  for  (c) 
we  develop  a  type  and  effect  system  that,  for  each  expression  e,  assigns  an  effect  set  describing  the  set  of 
resources  accessed  in  the  evaluation  of  e. 

1.1  Contributions  and  Overview 

This  paper  makes  several  contributions: 

•  Our  access  control  system  is  static,  i.e.,  the  system  checks  for  access  violations  at  compile  time.  This 
is  similar  to  some  other  recent  research  (e.g.,  [12])  but  in  stark  contrast  to  common  implementations 
of  Java  and  CLR  where  violations  are  checked  at  run-time. 

•  Despite  being  static,  the  system  is  able  to  define  and  enforce  many  non-trivial  access  control  patterns 
through  its  ability  to  reason  about  locally  refined  access  control  policies. 

•  The  heart  of  our  formal  system  is  a  novel,  type-based  must  alias  analysis,  which  may  be  of  independent 
interest. 

•  We  have  a  proof  of  soundness  for  the  core  subset  of  the  system.  Our  system  is  sound  in  the  presence 
of  updatable  references,  higher-order  functions,  and  concurrency. 

Our  system  is  type-based,  relying  only  on  standard  techniques.  One  reason  for  choosing  a  type-based 
approach  is  compositional  verification.  Type  systems  explicitly  express  assumptions  about  the  environment 
of  each  program  fragment.  Therefore  program  components  may  be  checked  separately  under  compatible 
environments,  and  then  composed  to  form  a  well-typed  program. 

The  rest  of  the  paper  proceeds  as  follows.  Section  2  introduces  our  system  informally.  We  introduce 
the  important  features  of  the  system  step-by-step,  making  improvements  as  we  proceed.  Materials  up  to 
and  including  Section  2.2  are  sufficient  to  perform  late,  local  refinement  of  access  control  policies.  A  small 
example  is  given  in  Section  2.4.  To  enforce  local  access  policies  non-locally,  we  introduce  subkeys  and 
subnaming  in  Section  2.5.  Section  3  presents  the  static  system  formally  and  sketches  a  proof  of  soundness 
(the  complete  proof  appears  in  Appendix  A).  Section  4  shows  a  few  extensions  to  the  system.  Section  5 
discusses  our  system’s  relation  to  must  alias  analysis.  Section  6  discusses  related  work.  Section  7  concludes. 

2  Informal  Presentation 

This  section  informally  develops  the  key  ideas  in  our  access  control  system.  In  the  interests  of  clarity,  we 
present  some  of  the  material  introduced  in  Section  1  again,  but  in  a  more  leisurely  fashion  and  with  more 
examples.  The  formal  details  of  our  system  are  presented  in  Section  3. 

In  a  typical  implementation  of  a  dynamic  stack-based  access  control  system  (such  as  Java’s),  permissions 
are  objects  containing  strings,  and  the  run-time  system  checks  permissions  by  inspecting  the  strings  before 
each  access  of  associated  resources.  For  example,  permission  to  access  flight  information  on  flight  356  may  be 
represented  as  a  string  "Flight  Info  :  356".  Instead,  we  design  access  control  into  the  static  semantics 

of  the  language  so  that  the  type  system  can  precisely  track  access  control  policies. 
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We  introduce  key-pairs,  each  consisting  of  a  limit  key  and  a  grant  key.  Each  key-pair  is  used  to  group 
resources.  Limit  keys  are  used  to  limit  access  to  resources  and  grant  keys  are  used  to  grant  access  to  resources. 

We  consider  every  program  value  (e.g.  a  function,  a  pointer,  etc)  to  be  a  resource  possibly  associated 
with  some  key-pair.  Key-pairs  are  named  in  the  static  system  using  an  infinite  set  Names.  That  is,  each 
p  G  Names  identifies  a  key-pair.  While  technically  p  is  a  static  name  for  a  run-time  key-pair,  for  brevity  we 
say  “the  key-pair  p”  instead  of  “the  key-pair  identified  by  p”  when  there  can  be  no  confusion. 

Each  type  r  in  our  system  consists  of  a  name  and  a  raw  type.  A  resource  of  the  raw  type  u  associated 
with  the  key-pair  p  is  given  the  type  p  ct;  we  say  that  p  qualifies  a  in  this  type.  For  example,  each  pointer 
type  is  of  the  form  p  ref^r). 

The  limit  (resp.  grant)  key  part  of  the  key-pair  p  has  the  raw  type  Ikey  (p)  (resp.  gkey  (p)).  Keys  are 
themselves  program  values.  Therefore  keys  may  also  be  under  access  control,  and  thus  are  associated  with 
a  key-pair.  A  limit  (resp.  grant)  key  p  associated  with  the  key-pair  pi  is  given  a  type  pi  Ikey  (p)  (resp. 
Pi  gkey  (p)). 

Finally,  we  use  T  ct  to  denote  the  type  of  a  program  value  not  associated  with  any  key-pair.  Such  program 
values  are  not  subject  to  access  control,  hence  they  may  be  accessed  by  any  code. 

2.1  Limit  and  Grant 

To  limit  access  rights,  we  introduce  the  syntax  form 

limit  ei,  62, . . . ,  e„_i  in  e„ 

where  Ci,  62,  . . . ,  e„_i  are  the  limit  keys  and  e„  is  the  code  whose  access  rights  are  limited  to  the  resources 
associated  with  the  keys  Ci,  62,  . . . ,  e„_i. 

Let  Ikey  be  the  limit  key  of  key-pair  p.  Assume  that  the  function  h  and  the  pointer  t  are  associated 
with  Ikey,  and  consider  this  definition: 

g  =  Ax.  limit  Ikey  in  x(h,  !  t) 

Since  g  dereferences  t,  g  can  be  called  only  by  code  with  access  to  t.  For  example,  the  following  code  should 
be  rejected  if  the  limit  key  akey  is  not  associated  with  t.  (A(xi, . . . ,  x„).e  is  a  function  of  n  arguments.) 

limit  akey  in  g  (A(x,  y).y) 

Moreover,  because  the  access  rights  of  the  body  of  g  are  limited  to  resources  associated  with  Ikey,  the 
function  passed  to  g  may  only  access  resources  associated  with  Ikey.  So  if  Ikey  is  associated  only  with  h 
and  t,  then  g  is  forbidden  from  accessing  any  resource  but  h  or  t.  For  example,  if  u  is  a  pointer  not  equal 
to  t  (and  is  not  qualified  with  T) 

g(A(x,y).!  u) 


is  forbidden. 

Now  that  we  have  seen  how  to  limit  access  rights,  we  turn  to  granting  access  rights.  We  introduce  the 
syntax  form 

grauit  Cl  in  62 

where  ei  is  a  grant  key  and  62  is  the  code  granted  access  to  the  resources  associated  with  key  Ci.  Note 
that  grauit  takes  only  a  single  expression  as  an  argument,  in  contrast  to  limit,  because  multiple  sequential 
grants  can  be  used  to  grant  a  set  of  permissions,  where  multiple  sequential  limits  will  limit  access  to  the 
intersection  of  access  rights  in  the  limit  expressions. 

Let  gkey  be  the  grant  key  part  of  the  key-pair  p.  The  code  below  grants  itself  access  to  the  resources  h 
and  t  in  order  to  call  g. 

grant  gkey  in  g  {\{x ,  y) .x  {y)) 
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A  grant  is  stronger  than  a  limit  because  it  enables  unconditional  access  to  the  resources  regardless 
of  what  access  rights  are  available  to  the  code’s  context.  In  Java,  the  analog  of  limit  is  the  permissions 
attached  to  traversed  methods  and  the  analog  of  grauit  is  the  initial  set  of  permissions  granted  for  an 
execution  thread  and  additional  accesses  granted  by  the  special  form  doPrivileged. 

We  use  a  type  and  effect  system  [7,  9]  to  statically  check  access  control  policies.  For  each  expression,  we 
assign  an  effect  set  conservatively  approximating  the  expression’s  access  rights.  Effect  sets  are  finite  sets  of 
key-pair  names.  The  type  checking  rules  derive  judgments  of  the  form  F  h  e  :  t;  L  (read  “the  expression  e 
has  the  type  r  in  the  type  environment  F  and  requires  access  rights  L”).  For  example,  the  type  checking 
rule  for  pointer  dereferences  is: 

F  F  e  :  p  re/(T);  L 
F  h  !  e  :  r;  L  U  {p\ 

This  rule  says  that  the  dereference  of  a  pointer  is  well- typed  if  the  access  to  the  pointer  is  enabled. 

The  type  checking  rule  for  limit  is  more  elaborate: 

For  1  <  t  <  n  —  1,  F  h  Ci  :  p'  Ikey  (pi);  Li 
F  F  €-n  ■  tn,  L^  F  F  L^  C  (pi,  P2,  .  ■  .  ,  Pn— l} 

F  F  limit  61,62, . . .  ,e„_i  in  e„  :  t„;  L„  U  Ui<i<n-i(-^i  U  {p'}) 

The  second  line  says  that  the  body  of  the  expression,  e„,  only  accesses  the  resources  associated  with  the 
key-pairs  pi,  p2, . . . ,  Pn-i-  In  the  conclusion,  note  the  presence  of  requires  that  the  context  have  the  right 
to  access  the  key-pairs  in  L„;  this  prevents  e„  from  gaining  more  access  rights  than  its  context.  On  the  first 
line,  since  each  key  et  is  itself  a  resource,  it  is  associated  with  a  key-pair  p'  (if  it  is  not  associated  with  any 
key-pair  then  p'  =  T).  Moreover,  evaluating  each  e^  may  also  involve  resource  accesses,  approximated  by 
Li.  Therefore,  the  context  must  have  access  rights  to  the  resources  associated  with  key-pairs  identified  by 
Ui<i<„_i(Ti  U  Ip'}),  which  is  included  in  the  overall  effect. 

The  type  checking  rule  for  grant  is  simpler: 

F  F  61  :  Pi  gkey{p2);Li 

_ F  F  62  :  r;L2  U  {P2} _ 

F  F  grant  61  in  62  :  r;  Ti  U  L2  U  {pi} 

The  key  61  is  required  to  have  a  type  of  the  form  pi  gkey  (P2),  and  62  is  granted  the  access  to  the  resources 
associated  with  the  key-pair  p2  as  indicated  by  the  presence  of  {P2}  in  62 ’s  effect.  However,  unlike  with 
limit,  the  context  need  not  have  access  to  p2. 

Grant  keys  are  dangerous  because  they  enable  unconditional  access  rights  regardless  of  the  context.  Hence 
programmers  should  prevent  arbitrary  code  from  using  grant  keys  and  gaining  unwanted  access  rights.  By 
splitting  keys  into  key-pairs  instead  of  using  a  single  key  for  both  limiting  and  granting,  we  have  sought  to 
make  it  easy  to  isolate  and  control  the  ability  to  grant  access  to  resources.  In  particular,  this  design  allows 
programmers  to  code  in  a  style  where  each  grant  key  is  forgotten  immediately  after  it  is  used  to  grant  the 
access  right  to  the  code  that  generated  the  key. 

Nevertheless,  grant  keys  can  be  useful  outside  of  this  trivial  style  as  long  as  they  are  used  with  discretion. 
As  an  example,  consider  system  calls  in  the  UNIX  operating  system.  Application  programs  are  usually 
prohibited  from  accessing  system  resources  such  as  printers  except  through  system  calls.  We  can  emulate 
the  behavior  of  such  a  protocol  using  grant  keys.  Let  all  printers  be  associated  with  the  grant  key  kqjrinters. 
Then  the  system  function  print  can  be  written 

A(a;,  p). grauit  k_printers  in  { 

.../*  code  for  outputting  x  to  the  printer  y  */  } 

so  that  a  program  that  does  not  have  access  to  the  printers  may  print  by  calling  this  function.  ^ 

^The  Java  security  model  has  a  similar  feature:  doPrivileged  enables  a  code  to  access  more  resources  than  are  available  to 
the  code’s  context. 
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2.2  Associating  Resources  with  Key-Pairs 

We  next  introduce  the  syntax  forms  newkey  to  generate  new  key-pairs  and  associate  e  i  with  62  to  associate 
resources  with  key-pairs.  The  syntax  form  newkey  <  e,  which  generates  new  subkey-pairs,  is  introduced 
together  with  subnaming  in  Section  2.5. 

We  first  describe  newkey.  We  use  existential  types  to  guarantee  that  different  key-pairs  (particularly 
those  generated  by  the  same  syntactic  occurrence  of  newkey)  are  identified  by  different  names. 


r  h  newkey  :  _L  (3p._L  (_L  Ikey  (p),  _L  gkey  (p)));  0 

Raw  tuple  types  are  written  (ti,  . . . ,  r„).  For  extracting  grant  (resp.  limit)  keys  from  a  pair,  we  define  IKey 
(resp.  gKey)  as  the  projection  function  Aa:.(x.l)  (resp.  Aa:.(a;.2)). 

Note  that  the  type  of  a  newly  generated  key-pair  is  qualified  with  _L,  i.e.,  by  default  the  new  key-pair  is 
not  associated  with  any  key-pair  and  hence  is  available  to  any  code.  Other  program  values  are  also  qualified 
with  _L  when  they  are  created,  also  making  them  available  to  any  code.  For  example,  the  type  checking  rule 
for  allocating  a  new  store  location  (i.e.  a  new  pointer)  is 

F  h  e  :  t;  L 

F  F  ref  e  :  _L  re/(r);  L 

In  our  system,  each  association  between  a  key  and  a  resource  occurs  after  both  the  key  and  the  resource 
are  created,  i.e.,  associations  happen  late.  We  use  the  syntax  form 

associate  ei  with  62 

to  associate  the  resource  ei  with  the  key-pair  with  limit  key  62-^  The  type  checking  rule  for  associate  is 
shown  below. 

F  F  ei  :  Pi  a;Li _ F  F  62  :  P2  Ikey  (p3);T2 

F  F  associate  ei  with  62  :  ps  cr;  Li  U  L2  U  {pi,  P2} 

The  associate  construct  is  similar  to  type  casting.  That  is,  given  a  resource  of  the  type  pi  cr,  associating 
it  with  the  key-pair  pa  has  the  effect  of  casting  the  type  to  ps  a. 

In  the  rule  for  associate,  because  the  limit  key  62  may  itself  be  associated  with  some  key-pair  (identified 
by  P2),  we  assert  that  the  context  must  hold  the  access  right  to  p2.  We  assert  that  the  context  must  also 
have  access  to  the  resource  ei,  and  this  is  indicated  by  the  inclusion  of  pi  in  the  effect  set  of  the  conclusion. 
To  see  why  this  condition  is  necessary,  consider  the  code  below  which  might  not  be  permitted  to  access  the 
pointer  ptr  but  nevertheless  is  able  dereference  it  by  generating  a  new  key-pair,  enabling,  and  associating 
ptr  with  it.  (The  form  open  x  =  e  unpacks  the  existential  package  e.) 

open  akeypair  =  newkey; 
grant  gKey (akeypair)  in  { 

ptr_casted  =  associate  ptr  with  IKey (akeypair) ; 

!  ptr_casted;  /*  ptr  accessed  */ 

} 

This  code  would  type  check  if  pi  were  missing  from  the  effect  set. 

2.3  Preventing  Resource  Forging 

Pointers,  i.e.  store  locations,  are  naturally  unforgeable  in  a  strongly  typed  language  that  does  not  admit 
explicit  pointer  manipulations  such  as  casting  an  integer  to  a  memory  address.  In  our  system,  keys  are  also 
unforgeable.  But  many  other  resources  are  forgeable.  For  example,  any  program  can  duplicate  any  pure 
function  consisting  only  of  variables  and  A’s  by  simply  having  another  instance  of  the  function. 

^We  can  also  allow  associating  via  grant  keys  and  key-pairs  themselves,  as  used  in  the  example  in  Section  1.  However,  the 
ability  to  associate  via  limit  keys  is  important,  as  it  eliminates  the  need  to  expose  grant  keys  (either  alone  or  in  key-pairs)  for 
this  purpose. 
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Our  system  does  not  automatically  prevent  such  resource  forging.  This  sounds  unsafe  because  if  a 
resource  is  forgeable  then  any  code  may  re-create  it  and  use  the  resource.  Consider  the  file  access  control 
policy  from  Section  1.  If  file  resource  are  strings  containing  the  actual  file  name  in  the  file  system,  then  in 
any  language  with  normal  string  operations  it  is  trivial  to  create  from  scratch  any  file  name  with  no  access 
controls  whatsoever. 

Fortunately,  such  situations  usually  can  be  remedied  easily.  In  the  file  access  control  example,  we  can 
define  file  resources  to  have  an  abstract  data  type  ([10])  File  defined  in  a  program  component  File  Mauiager. 
The  representation  of  a  File  could  be  a  string  type,  but  this  would  not  be  visible  outside  of  the  File  Manager 
component.  In  this  design.  File  Manager  would  handle  all  file  operations  directly  via  system  calls,  and  all 
other  components  would  be  required  to  go  through  File  Manager.  This  can  be  made  possible  by  using  the 
access  control  mechanism  to  ensure  that  only  File  Mcuiager  has  access  to  file-related  system  calls.  When 
requesting  some  file  for  the  first  time,  a  component  must  ask  File  Manager  for  the  appropriate  File  resource 
referring  to  the  requested  file.  We  also  give  File  Mauiager  a  type  signature  such  that,  for  example,  calling 
the  File  writing  function  would  have  the  effect  of  accessing  the  given  File  resource.  Then  File  Mcuiager 
component  can  ensure  that  File  resources  are  unforgeable  so  as  to  allow  access  control  on  files  by  associating 
File  resources  with  key-pairs. 

In  our  system,  we  assume  that  a  programmer  takes  necessary  steps  to  make  resources  unforgeable  if  he 
wishes  to  have  them  under  access  control.  For  a  naturally  unforgeable  resource  like  a  pointer  or  a  key,  this 
can  be  as  simple  as  associating  the  resource  with  some  key-pair  shortly  after  creating  it  and  before  making 
it  available  to  other  parts  of  the  program.  For  other  resources,  use  of  abstract  data  types  may  be  necessary, 
as  seen  in  the  File  example. 

2.4  Simple  Example 

The  system  described  thus  far  is  capable  of  expressing  some  fine-grain  access  control  policies.  Consider  the 
following  code  which,  for  each  node  of  the  linked  list  g,  applies  the  function  p  to  the  item  field  of  the  node. 

t  :=  g; 

while  (t  yf  nil)  { 
p(t . item) ; 
t  :  =  (  !  t) .next ; 

} 

Let  p  yf  T.  Let  g  have  the  record  type  NodeType  defined  below.  (We  take  the  liberty  of  using  a  C-like 
structure  declaration  for  simplicity.) 

NodeType  =  p  { 
p ItemType  item; 
p  re/ (NodeType)  next; 

}; 


(The  first  occurrence  of  p  is  not  a  binding  name;  it  just  qualifies  the  record  type.) 

We  would  like  to  use  the  system  to  limit  p  to  accessing  only  the  passed  t .  item.  In  particular,  we  want 
to  prevent  p  from  modifying  the  list  structure  of  g,  because  the  code  is  traversing  it.  We  may  do  this  by 
associating  each  t .  item  with  a  fresh  key  before  calling  p. 

t  :=  g; 

while  (t  y^  nil)  { 
open  akey  =  newkey; 
granit  gKey(akey)  in  { 

theitem  =  associate  t.item  with  IKey(akey); 
limit  IKey(akey)  in  {  p(theitem);  }; 
t  :=  (  !  t) .next; 

} 

} 
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Note  that  the  function  p  could  be  complicated,  potentially  calling  other  functions.  Nevertheless,  the 
type  system  is  able  to  ensure  that  each  function  application  only  accesses  the  specified  t .  item,  because  the 
lexically  scoped  name  (which  appears  when  the  new  key-pair  is  opened)  distinguishes  each  instance  of  akey 
and  its  late  binding  with  the  resource. 

This  example  shows  the  system’s  ability  to  declare  late,  local  access  control  policies.  That  is,  a  program¬ 
mer  may  store  a  collection  of  resources  uniformly  with  the  same  type,  and  when  there  is  a  need  for  finer 
access  control  (e.g.  at  the  level  of  individual  resources  in  the  collection)  the  key-associations  are  refined. 

2.5  Subkeys  and  Subnaming 

We  now  introduce  subkeys,  and  their  corresponding  static  representation  using  subnaming.  These  additions 
require  a  few  changes  to  features  explained  earlier.  To  motivate  the  introduction  of  subkeys,  we  illustrate 
the  problem  that  we  would  encounter  if  the  system  did  not  support  them. 

Consider  the  file  access  control  example  from  Section  1.  Recall  that  the  key-pair  shared  jtiles  is  asso¬ 
ciated  with  the  files  shared  between  the  program  components  C  and  D.  Let  Pshared  identify  sharedJiles. 
Below,  the  code  for  C  is  re-written;  in  particular,  it  uses  newkey  instead  of  newkey<  shared  Tiles  to  generate 
the  key-pair  somejfiles. 

[Component  C] ; 

open  somejfiles  =  newkey; 

...associate  file_a  with  IKey (some Tiles) ; 

...associate  fileJs  with  IKey(someTiles)  ; 

f  =  Ax. limit  IKey (someTiles)  in 

.../*  accesses  the  selected  files  */ 


In  the  code  above,  f  gets  the  type 

I  /  {psomel  N 
-L  (ri  — >  T2) 

where  psome  identifies  the  key-pair  somejfiles.  Here,  the  set  above  the  arrow  is  the  latent  effect  of  the 
function,  as  usual  in  a  type  and  effect  system.  Because  psome  is  lexically  scoped  in  C’s  context  and  therefore 
invisible  in  D’s  context,  the  type  system  fails  to  type  check  D’s  call  to  f . 

The  problem  stems  from  the  inability  of  the  type  system  to  understand  local  associations  outside  of 
the  local  context  when  the  lexically  scoped  names  are  completely  anonymous.  This  prevents  non-local 
enforcement  of  locally  refined  policies. 

Our  system  solves  this  problem  by  allowing  the  programmer  to  declare  subset  relations  between  resources 
via  subkeys.  The  syntax  form  newkey <e  generates  a  new  immediate  subkey-pair  of  an  existing  key-pair.  As 
with  associate,  we  let  e  be  just  the  limit  key  part  of  the  key-pair;  again,  this  avoids  the  need  to  propagate 
the  grant  key  just  to  associate  resources  with  the  key-pair.  The  type  checking  rule  for  newkey <e  is 

_ r  h  e  :  Pi  lkey{p2)]L _ 

r  h  newkey<e  :  T  (dps  <  p2.T  (T  Ikey  {ps),  ±  gkey  (pa)));  L  U  {pi} 

Here,  in  the  bounded  existential  raw  type  dpa  <  p2. . . .,  the  key-pair  name  pa  is  the  bound  name  and  p2 
is  the  upper-bound  free  in  the  raw  type.  The  intuition  behind  this  rule  is  that  the  new  key-pair  should  be 
identified  by  some  fresh  name  pa  such  that  pa  <  P2.  The  subnaming  relation  <  statically  keeps  track  of  the 
subkey  hierarchy. 

Recall  that  any  resources  associated  with  a  key-pair  are  also  associated  with  its  super  key-pairs.  Thus 
resources  associated  with  a  key-pair  are  a  subset  of  its  superkey-pair’s  resources.  Then,  because  the  resources 
associated  with  the  key-pair  psome  are  a  subset  of  those  associated  with  the  key-pair  Pshared> 
shared jf lies  as  the  superkey-pair  when  generating  someTiles.  Here  is  the  code  from  Section  1  again 
(using  limit  keys  to  generate  and  associate). 


[Component  C] ; 

open  someJiles  =  newkey<lKey(shared Jiles); 

...associate  file_a  with  IKeyCsome Jiles) ; 

...associate  fileJj  with  IKey (some Jiles) ; 

f  =  Ax. limit  IKey (some jEiles)  in 

.../*  accesses  the  selected  files  */ 

Subnaming  induces  subeffecting  and  subtyping.  In  the  example,  the  type  system  can  reason  that  {psome}  < 
{Psharedl-  We  add  the  usual  type  checking  rules  so  that  a  subeffect  (resp.  subtype)  may  be  used  where  its 
supereffect  (resp.  supertype)  is  expected.  Here  we  have 

I  /  {psome  }  \  ^  I  /  ^^shared^  % 

_L  (ti  — >  T2)  <  -L  (ti  — >  T2) 

and  hence  f  can  be  called  by  a  context  having  access  to  p shared-  Now  D’s  call  to  f  type  checks. 

Without  subkeys  and  subnaming,  the  type  system  cannot  track  a  key/resource  association  outside  of 
the  context  of  the  code  in  which  the  association  is  made.^  The  key  observation  that  leads  to  subkeys  and 
subnaming  is  that  locally  associated  resources  (i.e.,  a  subkey)  can  be  viewed  as  a  local  refinement  of  some 
larger  collection  of  resources  that  is  recognized  (e.g.,  is  associated  with  a  superkey)  outside  the  local  context. 
In  this  way,  subkeys  and  subnaming  allow  the  programmer  to  define  late,  local  associations  that  can  be  used 
non-locally. 

To  better  understand  the  uses  of  subnaming,  we  present  a  larger  example.  Consider  an  airline  ticketing 
program  that  contains  two  components:  FlightCtrl  having  control  of  ticketing  and  seating  information  for 
all  flights  and  TicketAgt  representing  a  ticket  agent.  There  is  only  one  FlightCtrl  but  there  could  be  more 
than  instance  of  TicketAgt. 

Suppose  each  component  runs  its  own  execution  thread  and  that  only  read  access  to  the  seating  and 
ticketing  information  is  available  to  the  TicketAgt  thread,  but  TicketAgt  may  request  FlightCtrl  make 
modifications  to  the  ticketing  and  seating  arrangement.  Let  information  for  each  flight  be  represented  by 
the  bounded  existential  record  type 

Flightlnfo  =  3pi<paii_f lights  { 

J-lkey{pi)  key; 

Pi  Ticketinglnfo  tickets; 

Pi  Seatinglnfo  seats; 

P2  int  flightjiumber ; 

P2  re/(Flightlnfo)  next; 

}: 

The  FlightCtrl  thread  is  granted  access  to  PalUlights>  may  access  the  Flightlnfo  record  of  every 
flight. 

Recognizing  TicketAgt’s  request,  perhaps  after  some  authentication,  FlightCtrl  responds  by  retrieving 
the  flight  information  for  the  flight  being  requested: 

[FlightCtrl  Component] : 

if  (AuthTicketAgt (agentl ,  flight  jium)  { 
open  finfo  =  getFlightlnfo (flight  num)  ; 


The  TicketAgt  thread  does  not  have  write  access  to  the  tickets  or  seatings  fields  of  finfo,  so  it  cannot 
make  the  changes  by  itself.  But  it  may  create  a  function  that  does  the  job  when  called  by  FlightCtrl: 

®To  be  precise,  this  statement  is  true  up  to  absence  of  grant  keys.  In  fact,  without  subnaming,  the  grant  keys  must  be  used 
to  grant  unconditional  access  to  the  non-local  context  when  using  associations  non-locally.  Therefore  not  having  subnaming 
precludes  many  useful  stack-based  access  control  patterns. 
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[TicketAgt] : 

f_agent  =  Xx. 

.../*  Makes  changes  to 

f inf o . tickets  and  f info. seats  */ 

FlightCtrl  runs  f  ^gent  in  its  thread.  But  FlightCtrl,  not  fully  trusting  f  ^gent,  uses  the  access  control 
mechanism  to  check  that  f_agent  is  actually  limited  to  modifying  the  seating  and  ticketing  information  of 
the  specified  flight: 

[FlightCtrl  Component] : 

limit  f info. key  in  f .agent () 

The  type  system  guarantees  that  f  .agent  does  not  gain  unwanted  accesses  (such  as  write  access  to  flight 
information  for  other  flights). 

The  subnaming  relation  pi  <  PalUlights  implied  in  the  type  of  Flightlnfo  is  important.  Existential 
quantification  allows  the  program  to  operate  on  one  Flightlnfo  at  a  time.  Without  subnaming,  the  bound 
name  pi  would  become  completely  anonymous  when  the  existential  package  is  opened.  Then,  because  this 
would  mean  that  pi  is  a  name  unknown  to  FlightCtrl,  FlightCtrl  would  be  forbidden  from  accessing 
f info,  and  hence  would  be  unable  to  run  f  .agent.  Subnaming  allows  anybody  with  access  to  Palljflights 
to  perform  access  control  at  the  level  of  individual  Flightlnfo  instances. 

We  can  take  this  example  a  step  further.  Suppose  that  TicketAgt  also  has  its  own  set  of  resources  asso¬ 
ciated  with  the  key-pair  Pagt-  Assume  that  f. agent  accesses  some  of  these  resources  and  that  FlightCtrl 
has  access  rights  to  Pagt- 

Let  ThirdPartyLib  be  a  third  party  library  component  that  TicketAgt  uses  to,  say,  help  itself  calculate 
ticket  costs  and  print  out  information  on  the  terminal  screen.  To  let  ThirdPartyLib  use  some  of  its  resources 
in  a  controlled  manner,  TicketAgt  imposes  access  control  on  its  own  resources: 

[TicketAgt] : 


open  libj^ey  =  newkey; 

...associate  agt ^resources . a  with  IKey (lib iey) ; 

...associate  agt ^resources .b  with  IKey (lib iey) ; 

Let  Piib  identify  the  key-pairs  libJcey.  Now  suppose  that  f^gent  runs  functions  from  ThirdPartyLib. 
The  programmer  wishes  to  limit  the  resources  the  functions  can  use,  so  the  definition  of  f  ^gent  would  look 
like 


[TicketAgt] : 


f. agent  =  Ax.  { 

limit  IKey (lib Jiey)  in  { 

.../*  calls  ThirdPartyLib’ s  functions  */  } 


} 

Coming  back  to  FlightCtrl,  it  seems  reasonable  to  assume  that  the  FlightCtrl  thread  is  still  capable 
of  running  f. agent  because  it  has  accesses  to  TicketAgt’s  resources  as  well  as  the  flight  information. 

[FlightCtrl] : 


/*  agtJ^ey  is  the  key-pair  identified  by  Pagt  */ 
limit  finfo.key,  lKey(agt Jcey)  in  f.agent() 
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p  e  Names  U  {_L,  T}  x  e  Vars  m  G  Integers  L  Names  U  {_L,  T } 


raw  types  a 

types  r 

values  V 

expressions  e 


int  I  (ti,  T2,  . . . ,  T„)  I  re/(r)  |  n  T2  |  Vpi  <p2-T  \  3pi  <P2-t  \  Ikey  (p)  \  gkey  (p) 
pa 

m  I  Top  I  X  I  {vi,V2,  ■  ■  ■  ,Vn)  I  Xx'.T.e  I  Api<p2.v  I  pack  v  as  3p2<P3-T 
V  I  (ei,  62, . . . ,  e„)  I  e.z  I  ei  62  |  ref  e  |  Ci  :=  62  |  !  e  |  spawn  e  | 

6  [p]  I  pack  e  as  3p2<P3.T  \  open  x  =  Ci  as  r  in  62  | 

limit  61, 62, ... ,  6„_i  in  6„  |  gratnt  ei  in  62  |  newkey<6  |  associate  ei  with  62 


Figure  1:  Source  language 


But  because  we  did  not  create  lib_key  as  subkeys,  the  type  system  does  not  see  the  associations  made  in  the 
TicketAgt  component.  Indeed,  the  type  system  must  give  f  ^gent  the  type  _L  (ri  — ^  T2)  where  €  L, 
but  Piib  is  not  visible  to  FlightCtrl’s  context. 

Fortunately,  subkeys  provide  an  easy  one-line  fix. 

[TicketAgt]: 

open  lib_key  =  newkey<lKey(agtiey)  ;  /*  fixed  */ 

...associate  agt ^resources . a  with  IKey (lib iey) ; 

...associate  agt  ^resources .b  with  IKey (lib  iey) ; 

Now  the  type  system  may  give  f_agent  the  type  _L  (ti  T2)  where  L'  contains  Pagt  instead  of  Piib- 
Then  the  system  is  able  to  type  check  the  call  to  f_agent  in  the  FlightCtrl  thread. 

3  Formal  System 

We  next  formally  present  the  core  subset  of  our  access  control  system  and  prove  its  soundness. 

Figure  1  shows  the  source  language,  which  consists  of  call-by-value  first-class  functions  with  primitives  for 
imperative  store  operations  and  concurrency.  The  language  is  rather  spare,  missing  a  few  bells  and  whistles 
seen  in  earlier  sections  for  brevity  (e.g.,  while  and  record  types).  These  features  can  easily  be  added.  We 
briefly  explain  the  syntax. 

As  before,  each  type  r  consists  of  a  name  and  a  raw  type.  The  raw  types  are  integers  ink  tuples 
(ti, T2,  . . . , r„),  pointers  ref{T),  functions  ri  — ^  T2,  bounded  universal  types  ypi<p2.T,  bounded  existential 
types  3pi  <P2.t,  limit  keys  Ikey  (p),  and  grant  keys  gkey  {p).  In  bounded  quantified  types,  the  name  on  the 
left  of  <  is  the  bound  name  and  the  name  on  the  right  is  the  upper-bound  free  in  the  raw  type. 

A  program  value  v  is  either  an  integer  m,  the  constant  limit  key  Top,  a  variable  x,  a  tuple  {vi,V2,  ■  ■  ■ ,  x„), 
a  function  Ax  :  r.e,  a  bounded  polymorphic  abstraction  Api  <  p2.v,  or  a  bounded  existential  package 
pack  V  as  3p2<P3.T. 

A  program  expression  e  is  either  a  value  or  one  of  the  following  syntax  forms.  The  expression  (e  1, 62, ... ,  6„) 
creates  a  tuple.  The  expression  e.z  projects  the  zth  value  of  the  tuple  e.  The  expression  ei  62  applies  the 
function  ei  to  62.  The  expression  ref  e  allocates  a  new  store  location  and  initializes  it  to  e.  The  expression 
61  :=e2  assigns  62  to  the  store  location  ei.  The  expression  !  e  dereferences  the  pointer  (i.e.  the  store  location) 
6.  The  expression  spawn  e  spawns  a  new  thread  for  the  evaluation  of  e.  The  expression  e  [p]  instantiates 
the  bounded  universal  abstraction  e.  The  expression  pack  e  as  3p2  <  ps.T  creates  a  bounded  existential 
package  of  e.  The  expression  open  x  =  ei  as  r  in  62  unpacks  the  bounded  existential  package  ei  to  evaluate 
62.  Section  2  introduced  the  syntax  forms  limit  ei,  62, . . . ,  6„_i  in  e„,  grant  ei  in  62,  newkey  <  e,  and 
associate  ei  with  62. 

Expressions  and  types  are  equivalent  up  to  consistent  renaming  of  bound  names  and  variables. 
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(Int) 


r  h  m  :  _L  int,  %  ’  F  h  Top  :  _L  Ikey  (T); 

For  1  <  i  <  n,  T  \-  ei  :  Ti]  L 


(Top) 


x:t  €  r 


(Var) 


F  F  (ci,  62,  •  ■  •  ,  G-rt)  •  -L  (ti,  T2,  •  •  •  ,  Xri) ,  LJl<i<n 


(Tuple) 


F  h  X  :  t; 

F  F  e  :  p  (ti,T2,  . .  ■  ,Tn);  L 
F  F  e.z  :  Til  F  U  {p\ 


(Proj) 


F,  x:ri  F  e  :  T2;  F  F,x:riFo 
F  F  Xx'.Ti.e  :  F  (n  r2);  0 

F  F  e  :  r;  F 


(Fun) 


F  F  ei  :  p  (ti  ^  r2);  F2  F  F  62  :  n;  F3 
F  F  ei  62  :  T2;  Fi  U  F2  U  F3  U  {p} 


(App) 


F  F  ref  e  :  F  re/(T);  F 


(Ref)  rFei:pre/(r);Fi  F  F  62  :  r;  F2  F  F  e  :  p  re/(r);  F 


F  F  Cl  :=  62  :  r;  Fi  U  F2  U  {p} 
F  F  6  :  r; 


F  F  !  6  :  r;  F  U  {p} 


F  F  spawn  e  :  F  int,  0 


(Spawn) 


F,  pi<p2  F  V  :  t;0  F,pi<p2Fo  F  F  e  :  pi  (Vp2  <P3-t);  F  F  F  p4  <  ps 

- —  (Gen)  - 


F  F  Api  <p2-v  :  F  (Vpi  <p2.r) 

F  F  6  :  r[p3/pi];F _ F  F  p3  <  p2 

F  F  pack  6  as  3pi  <p2.r  :  F  (3pi  <p2.r);  F 


F  F  6  [p4]  :  t[p4/p2];FU  {pi} 


(Inst) 


(Pack) 


F  F  61  :  Pi  (3p2<p3.ri);Fi  F,  p2  <P3,  a;:Ti  F  62  :  T2;F2 

F  F  T2 _ F  F  F2 _ F,  P2<P3,x:ti  Fo 

F  F  open  x  =  61  as  ri  in  62  :  T2;  Fi  U  F2  U  {pi} 


For  1  <  z  <  n  —  1,  F  F  6i  :  p'  Ikey  (pi);  Li 
F  F  Bn  ■  Tji,  Lyi  F  F  F^  <  P2-!  ■  ■  ■  5  Pn— 1} 

F  F  limit  61, 62, . . . ,  6„_i  in  6„  :  r„;  F„  U  Ui<i<n-i(^*  F  {p'i}) 

F  F  6  :  Pi  Ikey  (P2);  F 


(Limit) 


F  F  newkey<e  :  F  (3p3  <  p2.F  (F  Ikey  (p2),F  pfcey  (P2)));  F  U  {pi} 
FF6i:pi(T;Fi  T  h  €2  ■  P2  Ikey  (ps);  L2 

(Associate ) 

r  h  associate  ei  with  €2  ‘  Ps  cr;  Li  U  L2  U  {pi^  P2} 


F  F  61  :  Pi  gkey  (p2);Fi 

_ F  F  62  :  r;F2  U  {p2} _ 

F  F  grant  6i  in  62  :  r;  Fi  U  F2  U  {pi} 

(NewKey) 


(Ope 


(Gr, 


F  F  6  :  Ti;  Fi  F  F  ti  <  r2  F  F  Fi  <  F2 
F  F  6  :  T2;  F2 


(Subsumption) 


Figure  2:  Type  checking  rules:  expressions 
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rhp 


T'r  p<p 


(Sub  Refl  p) 


r  h  Pi  <  /92  r  h  P2  <  P3 


r  h  Pi  <  p3 


(Sub  Trans  p) 


Pi<P2  G  r 


r  h  Pi  <  p2 


(Sub  p) 


rhp 


(Sul 


r  h  Pi  <  p2  r  h  (Ti  <  ct2 


r  h  Pi  (Ti  <  P2  0-2 
For  1  <  i  <  n,  V  \-  Ti  <  Ti 


(Sub  t) 


Fha 


r  I-  (n,  T2,  .  .  .  ,  T„)  <  (ri',  r2',  .  .  .  ,  Tn') 

r  h  p3  <  p2  r,  pi<p3 1- Ti  <  r2  r,pi<p3i-o 


r  h  CT  <  cr 

■  (Sub  Tuple) 


(Sub  Refl  cr) 


r  h  CTi  <  (72  r  h  (72  <  0-3 


r  h  T3  <  Ti  r  h  t2  <  t4  r  h  Fi  <  L2 


(Sub  Trans  cr) 


I  L2 

1  F  Ti  - >  T2  <  T3  - >  Ti 


(Sub  Fun) 


r  h  (Vpi<p2.Ti)  <  (Vpi<P3.T2) 

r  h  F 


(Sub  Univ) 


r  h  p2  <  P3  r,pi<p2  F  n  <  t2  r,  pi<p2Fo 


rF0<F 


(Sub  Effect  0) 


r  F  (3pi  <p2.ri)  <  (3pi  <p3.r2) 
r  F  Pi  <  p2  r  F  Li  <  L2 


r  F  Fi  U  {pi}  <  L2  U  {P2} 


(Sub  Effect  {p}) 


Figure  3:  Type  checking  rules:  subnaming,  subtyping,  subeffecting 


F  F  _L 

F  F  p  F  F  (7 


(Name  ±)  -  (Name  T)  — Pi  € -  (Name  p) 

F  F  T  F  F  Pi 


F  F  p  (7 


(Type) 


FFt 


F  F  re/(r) 
r,pi<P2FT  F,  Pi<P2Fo 


F  F  int 

(RType  Ref) 


For  1  <  z  <  n,  F  F  Ti 

(RType  Int)  - — — - ^ -  (RType  Tuple) 

T  F  (ri,r2, . . .  ,r„) 

FFti  FFt2  FFL 


TFri 


(RType  Fun) 


T2 


(RType  Univ)  T,  pi<p2  F  T - F,  pi<p2  Fo  Exists) 


FFp 


F  o 


F  F  Ikey  (p) 
(Env  0) 


FFVpi<p2.r  FF3pi<p2.r 

,  ,  T  F  p  ,  ,  For  each  p  G  T,  F  F  p 

(RType  LKey)  — — - ,  ^  (RType  GKey)  -  '  - 1—  (Effect) 

F  F  gkey  (p)  FFL 


FFr  FFo  x  ^  domCT)  F  F  p2  FFo  pi  ^  rfom(F)  U  {_L,  T} 

^  ^  ^  (Env  x)  - — - 1 1 —  (Env  p) 


F,  a;:r  F  o 


F,  pi<p2  F  o 


Figure  4:  Type  checking  rules:  well-formed  names,  types,  effects,  environments 
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3.1  Static  Semantics 

Type  environments  are  sequences  of  variable-to-type  bindings  and  names  annotated  with  a  supername. 

r  ::=  0  I  T,x:t  \  T,pi<p2 

Figure  2  shows  type  checking  rules  for  expressions.  The  meaning  of  F  h  e  :  t;  L  is  that  the  effect  set  L 
conservatively  approximates  e’s  access  rights.  A  program  is  a  closed  expression.  A  program  e  is  well-typed 
iff  0  h  e  :  r;  0  for  some  r,  i.e.,  iff  e  can  be  type  checked  with  no  enabled  access  rights.  Let  us  now  discuss 
some  of  the  important  points  in  the  type  checking  rules. 

As  explained  in  Section  2.5,  (NewKey)  assigns  a  bounded  existential  type  to  a  newly  created  key-pair. 
The  constant  Top  serves  as  the  initial  key.  (Top)  assigns  Top  the  limit-key  type  _L  Ikey  (T).  The  fact  that 
Top  is  not  a  grant  key  is  important,  as  otherwise  any  code  would  be  able  to  access  any  resource  by  granting 
itself  Top.  The  syntax  form  newkey  is  equivalent  to  newkey<Top. 

Subnaming  induces  subtyping  and  subeffecting  (see  Figure  3),  which  are  then  used  in  two  places:  (Sub¬ 
sumption)  and  (Limit).  (Subsumption)  allows  a  subtype  (resp.  subeffect)  to  be  used  wherever  its  supertype 
(resp.  supereffect)  is  expected.  (Subsumption)  formally  captures  the  intention  that  whatever  is  associated 
with  key-pairs  are  also  associated  with  its  super-key-pairs. 

(Limit)  replaces  the  rule  introduced  in  Section  2  by  using  the  subeffecting  relation  <  instead  of  the  subset 
relation.  This  is  needed  to  allow  contexts  with  access  rights  limited  to  some  key-pair  to  execute  a  code  with 
access  rights  limited  to  its  superkey-pair  when  the  code  accesses  only  what  are  allowed  by  the  context.  For 
example,  consider  the  following  function  g  which  takes  a  resource  and  accesses  it.  We  wish  to  limit  g’s  access 
rights  to  the  key-pair  g_key  identified  by  pg. 

g  =  Ap  <pg.  Ax :  p  CT.  limit  lKey(g_key)  in  ... 

The  type  system  can  give  the  g  the  raw  type 

Vp<Pg-(p  cr  M  r) 

for  some  cr  and  r  so  that  a  caller  whose  access  rights  are  locally  refined  with  respect  to  pg  is  able  call  g  with 
its  resource. 

Figure  3  also  shows  that,  as  usual,  subtyping  is  invariant  under  pointer  types.  Subtyping  is  also  invariant 
for  raw  key  types,  i.e.,  Ikey  (pi)  <  Ikey  (p2)  then  pi  =  p2,  and  analogously  for  grant  key  types.  It  is  easy 
to  see  that  covariant  keys  would  be  unsound  because  limiting  (resp.  granting)  pi  should  not  somehow  limit 
(resp.  grant)  p2  when  pi  <  p2  and  pi  yf  p2.  To  see  that  contravariance  also  fails,  observe  that  associating 
Pi  should  not  somehow  associate  p2  when  p2  <  pi  and  pi  yf  p2.^ 

Section  2  discusses  (Grant)  and  (Associate).  Recall  that  values  are  created  with  no  associated  key-pair. 
Thus  the  rules  for  introductory  forms  (Int),  (Tuple),  (Fun),  (Ref),  (Gen),  (Pack)  and  (NewKey)  all  qualify 
their  values  with  _L.  The  corresponding  eliminatory  forms  (Proj),  (App),  (Assign),  (Deref),  (Inst),  (Open), 
(Limit),  (Grant),  (NewKey)  and  (Associate)  that  use  the  values  require  an  effect  set  consistent  with  the 
required  access  rights.  Note  that  F  h  _L  <  p  for  any  F  h  p. 

As  usual  in  a  type  and  effect  system,  the  latent  effect  of  a  function  is  recorded  in  its  type  at  (Fun)  and 
used  at  (App). 

(Spawn)  implies  that  a  newly  spawned  thread  starts  without  any  access  rights.  We  could  alternatively 
have  the  spawned  thread  inherit  the  access  rights  of  the  spawner.  In  this  case,  we  would  add  the  rule 

F  h  e  :  t;  L 

-  (Spawn  alt) 

F  h  spawn  e  :  _L  ink,  L 

The  only  non-syntax  directed  rule  is  (Subsumption).  Effect  sets  are  finite  and  subtyping  is  structural,  so 
type  checking  is  decidable. 

^We  could  relax  invariance  by  assigning  a  pair  of  a  covariant  name  and  a  contravariant  name  for  each  key  type.  Here  we 
stick  with  invariance  for  simplicity. 
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3.2  Sketch  of  Type  Soundness 

We  sketch  a  proof  of  soundness.  A  complete  version  of  the  proof  appears  in  Appendix  A. 

The  first  step  is  to  define  a  dynamic  semantics  rich  enough  to  classify  an  access  violation  as  a  run-time 
error.  This  is  only  to  prove  soundness  of  the  system;  a  real  implementation  should  follow  a  straightforward 
dynamic  semantics  that  ignores  access  control  checks. 

We  introduce  the  set  KeyPairs  such  that  each  element  of  KeyPairs  denotes  a  key-pair.  Each  program 
value  is  now  annotated  with  a  key-pair,  with  the  intended  meaning  that  the  value  is  associated  with  the 
key-pair.  So  a  program  value,  say  the  function  Xx:T.e,  associated  with  the  key-pair  k  G  KeyPairs  is 

k  Xx'.T.e 

We  type  check  the  annotated  values  by  keeping  track  of  names  identifying  k  G  KeyPairs  in  the  type  envi¬ 
ronment. 

T  \k:p 

We  use  the  special  key-pairs  bot  and  top  to  denote  non-association  and  the  Top  key-pair,  respectively. 

The  dynamic  semantics  needs  to  track  enabled  accesses  for  each  context.  Like  in  an  eager  stack-inspection 
semantics,  we  maintain  exactly  the  enabled  accesses  in  the  syntax  form  access  A  in  e  where  A 
KeyPairs  U  {bot,  top}  denote  the  enabled  accesses  for  the  expression  e.  This  approach  makes  the  soundness 
proof  easy.  The  following  rule  is  used  to  type  check  access  A  in  e. 

Phe:  t;L  ri-L<{/3|ri-A::pfor  some  k  G  A} 
r  h  access  A  in  e  :  t;  0 

access  A  in  e  is  a  run-time  syntax  form  not  available  to  the  source  program.  Each  access  A  in  e  appears 
as  the  result  of  the  evaluation  of  limit  or  grant. 

Evaluation  is  defined  as  a  sequence  of  call-by-value  small-step  reductions  of  the  form 

(S',  AT,  (ei,e2,...,e„))  — >  (S',  AT',  (e},  63, . . . ,  e(j,)) 

where  ei,  62, . . . ,  e„,  e},  62, . . . ,  e(j/  are  the  execution  threads,  S,  S'  are  stores  mapping  store  locations  to 
program  values,  and  K,  K'  are  key-managers  representing  immediate  sub-key-pair  relation  between  key- 
pairs.  So  fci  is  a  (immediate  or  non-immediate)  sub-key-pair  of  k2  iff  ki  ^  k2  G  K*^  where  K*^  is  the 
reflexive,  transitive  closure  of  K  lifted  with  bottom.  In  this  section,  we  restrict  the  reduction  rules  to  the 
case  for  one  execution  thread  to  save  space. 

To  make  evaluation  fail  at  access  violations,  the  dynamic  semantics  checks  the  enabled  accesses  whenever 
a  program  value  is  used.  For  example,  when  calling  a  function  associated  with  the  key-pair  k,  the  dynamic 
semantics  checks  whether  k  is  enabled  in  the  current  set  of  access  rights  A. 

k  G  ClosexiA) 

{S,  K,  A[access  A  in  R[{k  Xx-.r.e)  u]]) 

— >  {S,  K,  A[access  A  in  A[e[v/a:]]]) 

CIosck  is  a  function  such  that  k  G  CloseK{A)  iff  A:  is  a  sub-key-pair  of  some  key-pair  in  A  in  the  key-pair 
relation  AT.  If  the  condition  k  G  ClosexiA)  is  false,  then  this  reduction  cannot  be  taken,  which  implies  that 
the  evaluation  for  this  thread  gets  stuck,  indicating  a  run-time  error. 

The  evaluation  contexts  E  and  R  are  used  to  And  the  redex  and  the  set  representing  the  enabled  accesses 
for  the  redex.  Intuitively,  A[access  A  in  R[e]]  means  that  e  is  in  an  evaluation  context  and  A  is  the  set  of 
its  enabled  accesses. 

We  use  the  special  constant  value  err  to  signal  a  run-time  error.  Whenever  an  execution  thread  gets 
stuck,  i.e.,  when  it  reduces  to  a  irreducible  non- value,  it  immediately  reduces  to  err.  Note  that  err  has  no 
type. 

As  mentioned  before,  limit  and  grant  introduce  occurrences  of  access  A  in  e.  The  new  access  rights 
B  after  limit  is  reduced  is  the  intersection  of  the  previous  access  rights  A  with  those  specified  in  limit. 
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(Here  Ikey  (fc)  denotes  the  limit  key  value  (unannotated)  of  the  key-pair  k.) 

{k[,k2, . . . ,  k'„}  C  CloseK{A) 

B  =  ClosexiA)  n  Closexilki, . . . ,  fc„}) 

{S,  K,  i?[access  A  in  R[ 
limit  k[  Ikey  (fci),  ...,k'„  Ikey  (fc„)  in  e]])  — > 

(S',  K,  i?[access  A  in  i?[access  B  in  e]]) 

In  contrast,  the  new  access  rights  B  after  grant  is  reduced  is  the  union  of  the  previous  access  rights  A  with 
those  specified  in  grant.  (Here  gkey  (k)  denotes  the  grant  key  value  (unannotated)  of  the  key-pair  k.) 

ki  G  ClosexiA) 

_ H  =  Aulfca} _ 

(S,  if,  if  [access  A  in  i?[grant  ki  gkey  (^2)  in  e]]) 

- >  (S,  if,  if  [access  A  in  ii[access  B  in  e]]) 

The  reduction  for  associate  is  relatively  simple.  Here  r  is  an  unannotated  program  value.  The  reduction 
changes  r’s  annotation  from  ki  to  k^. 

{^1,^2}  C  CloseK{A) 

(S,  if,  if  [access  A  in  R[ 

associate  ki  r  with  k2  Ikey  (fta)])) 

— >  (S',  if,  if  [access  A  in  i?[fc3  r]]) 

The  reduction  for  newkey  creates  a  new  key-pair  k^  as  the  immediate  sub-key-pair  of  k2- 

ki  G  ClosexiA)  fcs  ^  dom{K)  U  {hot,  top} 

(S,  if,  if  [access  A  in  i?[newkey<A:i  Ikey  (^2)]])  — > 

(S,  if  U  {ks  1-^-  ^2},  if[access  A  in  i?[u[]) 

where  v  is  the  existential  package  containing  the  new  key-pair  value  (not  shown) . 

Appendix  A.l  shows  the  complete  dynamic  semantics. 

Recall  that  we  have  intentionally  enriched  the  dynamic  semantics  with  explicit  key-pairs  just  so  that 
we  could  identify  access  violations.  A  real  implementation  of  the  run-time  system  does  not  need  key-pairs 
because  our  type  system  checks  for  access  violations  at  compile  time. 

The  next  step  is  to  define  a  well-typed  program  state. 

Definition  1  T  h  (A,  if,  (ei,  62, ... ,  e„))  (read  “the  program  state  {S,  if,  (ei,  62, ... ,  e„))  is  well-typed  under 
T”)  tff 

(1)  Tho. 

(2)  For  each  1  <i  <n,  T  h  :  r^;  0  for  some  Ti. 

(3)  £  G  dom{S)  iff  £  G  dom{T). 

(4)  k  G  dom{K)  iff  k  G  dom{T). 

(5)  X  ^  dom{T). 

(6)  If  T  \-  £  :  T  and  S{£)  =  V  then  T  \-  V  :  . 

(7)  Suppose  T  \-  ki  :  Pi  and  T  \-  k2  ■  P2-  Then  T  \-  pi  <  p2  iff  ki  ^  k2  G  if)}. 

The  first  condition  says  that  T  must  be  well-formed.  The  second  condition  says  that  each  execution  thread 
is  well- typed  under  T  with  effect  set  0.  The  third  and  the  fourth  conditions  say  that  T  and  S',  if  must  have 
matching  store  locations  and  key-pairs.  The  fifth  condition  says  that  T  must  not  contain  variables.  The 
sixth  condition  expresses  the  usual  we  11- typed  store  condition.  The  last  condition  says  that  the  key-manager 
if  contains  exactly  the  sub-key-pair  relationship  implied  by  the  type  environment  T. 

Recall  that  err  is  non-typable.  The  soundness  proof  then  reduces  to  showing  the  following  theorem. 
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Theorem  1  (Subject  Reduction)  IfT  h  {S,K,^  and  {S,K,e)  — >  {S' ,K' then  there  is  F'  such  that 
T'  h  {S',K',^. 


The  theorem  is  proved  by  induction  on  the  type  derivation  and  case  analysis  on  reduction  kinds.  The 
immediate  corollary  is  that  a  well- typed  program  does  not  cause  access  violations. 

4  Extensions 

We  next  discuss  a  few  possible  extensions  to  the  system. 

4.1  Run-Time  Checks 

Our  system  is  powerful  enough  to  statically  enforce  many  fine-grain  access  control  policies.  But  the  pro¬ 
grammer  may  still  encounter  situations  where  the  static  checking  feels  overly  restrictive.  We  may  extend 
our  system  with  run-time  checks. 


r  h  Cl  :  Pi  lkey{p2)]Li 
r  h  62  :  t;  L2  U  {P2}  F  h  63  :  t;  L2 
F  h  have-access  ei  ?  62  63  :  r;  Li  U  L2 

The  syntax  form  have-access  ei  ?  62  63  checks  whether  the  current  context  has  ei  enabled,  and  if  so 
evaluates  62  or  else  evaluates  63. 

The  disadvantage  of  this  extension  is  that  the  run-time  system  now  must  track  key  values  and  enabled 
access  rights.  Without  this  extension,  our  system  is  completely  static,  and  therefore  a  program  with  access 
control  has  no  run-time  overhead  over  an  equivalent  program  without  access  control.  Nevertheless,  even 
with  this  extension,  the  run-time  system  only  needs  to  check  enabled  access  rights  at  have-key’s.  Hence  the 
overhead  should  be  minimal. 

4.2  Effect  Kinds 

In  our  airline  ticketing  example,  we  assumed  that  the  TicketAgt  thread  has  read  access  but  not  write  access 
to  the  flight  information.  Strictly  speaking,  the  system  we  described  cannot  distinguish  different  kinds  of 
effects  on  the  same  resource. 

It  is  easy  to  extend  the  system  with  effect  kind  constants  for  the  primitives  in  the  language  (e.g.,  distin¬ 
guishing  the  effect  of  dereferencing  from  the  effect  of  assigning  or  associating)  and  programmer-defined  effect 
kind  variables  (e.g.,  the  effect  kinds  readSeating,  editSeating  for  Seatinginf o).  Effect  kinds  qualify  effects, 
i.e.,  each  effect  is  now  of  the  form  p  p  where  p  is  an  effect  kind.  Then  the  programmer  may,  for  example, 
limit  e’s  access  to  only  reading  a  selected  Seatinginfo  by 

limit  readb'eatmpCtheseatingiey)  in  e 

and  the  type  system  checks  that  e’s  effect  set  is  a  subeffect  of  {readSeating  p},  where  p  identifies  theseating_key. 

4.3  Type  Variables,  Effect  Variables,  and  More 

We  restricted  the  formal  system  to  just  bounded  quantified  types  over  names  to  make  the  presentation 
concise.  But  because  the  system  relies  only  on  standard  type-system  techniques,  it  is  straightforward  to 
extend  the  system  with  type  variables  and  effect  variables  so  as  to  admit  bounded  quantification  over  them. 

Existentially  quantified  type  variables  naturally  encode  abstract  data  types  [10].  We  may  also  want  a 
native  support  for  parameterized  recursive  data  types.  A  practical  implementation  may  be  to  add  recursively- 
defined  named  data  types  seen  in  languages  like  ML. 
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5  Relation  to  Must  Alias  Analysis 

We  briefly  discuss  the  relation  between  our  access  control  system  and  must  alias  analysis.  In  order  to  express 
locally  refined  access  control  policies,  our  access  control  checks  constraints  of  the  form  “resources  used  by 
the  expression  e  must-alias  one  of  the  resources  in  the  set  A,”  where  A  may  be  defined  locally.  The  first 
step  toward  this  goal  is  generation  of  lexically  scoped  names  and  late  binding  of  names  with  program  values. 
Lexically  scoped  names  allow  the  creation  of  new  names  distinguishable  from  other  names,  and  late  binding 
allows  existing  program  values  to  be  must-aliased  with  these  names.  Together,  they  support  creation  of  fine 
must-aliasing  relations.  Note  that  relations  are  not  lexically  scoped;  they  may  be  transported  outside  of  a 
lexical  scope  by  existential  or  universal  name  quantification. 

However,  there  is  a  problem  when  these  names  are  left  disjoint.  The  problem  occurs  when  the  names 
collide  (with  other  names  or  with  their  lexical  boundaries),  for  example,  when  the  type  system  needs  to  equate 
two  types  differing  in  names.  The  problem  becomes  more  severe  in  a  setting  like  stack-based  access  control 
because  names  propagate  and  collide  not  only  through  types  of  expressions  but  also  through  their  effects. 
This  is  the  problem  subnaming  solves.  With  subnaming,  names  are  no  longer  disjoint.  So  the  type  system  is 
able  to  make  compromises  by  using  supernames  when  possible.  This  has  the  effect  of  “downgrading”  a  fine 
must-aliasing  relation  to  a  coarser  one. 


6  Related  Work 

Stack-based  access  control  is  used  in  Java  [8]  and  the  CLR  [4].  Pettier  et  al  [12]  present  a  type  system  that 
can  statically  check  a  subset  of  Java’s  access  control  policies.  Their  system  is  faithful  to  the  Java  security 
model  and  hence  conservatively  approximates  Java’s  dynamic  access  control.  It  is  not  our  goal  to  match 
Java’s  access  control  system,  but  we  believe  it  is  possible  to  encode  Java’s  mechanism  in  a  way  so  that  access 
policies  enforceable  by  Pettier  et  al’s  system  can  also  be  enforced  by  ours.  We  also  believe  that  our  system 
is  more  expressive,  because  of  its  ability  to  locally  refine  access  control  policies. 

The  implementation  of  run-time  systems  for  stack-based  dynamic  access  control  is  a  research  subject  in 
itself.  In  addition  to  direct  inspection  of  the  execution  stack  at  run-time,  which  is  done  by  Java  and  the 
CLR,  several  other  techniques  have  been  proposed.  One  approach  is  security-passing  style  where  enabled 
access  rights  are  explicitly  passed  as  function  arguments  [15].  Also,  an  implementation  technique  based  on 
code  instrumentation  has  been  proposed  [13].  We  believe  that,  should  the  need  for  run-time  checks  arise  in 
our  system  (e.g.,  as  discussed  in  Section  4.1),  we  can  add  such  checks  using  any  of  these  techniques.  Besides 
efficient  implementation,  studying  dynamic  semantics  has  lead  to  a  deeper  understanding  of  the  stack-based 
access  control  mechanism  [15,  6] .  It  is  interesting  to  note  that  Pettier  et  al  [12]  first  develop  their  static  system 
on  the  security-passing-style  converted  language,  then  translate  back  to  obtain  a  corresponding  system  for 
the  source  language. 

There  are  a  variety  of  ways  to  perform  access  control  besides  the  stack-based  approach.  Abadi  et  al 
[1]  present  a  system  based  on  examining  execution  history.  Their  system  is  a  generalization  of  the  stack- 
based  mechanism  where  the  access  rights  at  a  point  in  time  are  determined  not  only  by  the  access  rights 
encoded  in  the  stack  but  also  by  those  of  functions  that  have  already  returned.  Using  our  syntax,  their 
system  roughly  can  be  explained  as  splitting  limit  into  start_Limit  and  endlLimit  and  analogously  for 
grant.  Statically  checking  history-based  policies  in  a  convincing  manner  would  require  reasoning  about  the 
sequential  behavior  of  programs,  and  it  is  unclear  whether  we  would  be  able  to  adapt  our  system  to  statically 
checking  history-based  access  control  policies. 

Researchers  have  also  proposed  systems  for  statically  enforcing  generic  security  policies.  These  systems 
include  Hoare  style  proof-systems  [11,  3]  and  a  higher-order  type  system  [14].  One  of  their  goals  is  a  portable 
framework  that  is  less  tied  to  the  source  language.  It  is  difficult  to  compare  our  system  with  these  as  the 
problem  domains  are  so  different. 

Our  system  is  an  application  of  type  and  effect  systems  [7,  9].  Type  and  effect  systems  are  widely  used 
for  checking  non-standard  program  properties;  the  work  of  Pottier  et  al  also  uses  a  type  and  effect  system 
[12].^ 

Finally,  there  is  a  connection  to  work  on  aliasing  control,  particularly  previous  work  on  the  programming 
construct  restrict,  originally  studied  in  [5]  and  extended  in  [2].  Briefly,  restrict  is  a  mechanism  for 
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specifying  and  checking  local  non-aliasing  of  store  locations.  To  this  end,  abstract  location  names  are  used 
to  approximate  store  locations  so  that  location  names  distinguish  local  aliases  of  store  locations  from  other 
aliases.  Beyond  what  has  been  previously  published  on  this  subject,  we  noticed  that,  instead  of  using 
incomparable  location  names,  we  could  use  subnaming  so  that  each  local  alias  of  a  set  of  store  locations  S 
is  a  subtype  of  the  type  of  all  aliases  of  S.  This  captures  the  notion  that  each  local  alias  is  a  refinement  of 
the  set  of  all  aliases.  Our  use  of  subnaming  for  refinement  of  access  control  policies  exploits  the  same  idea. 

7  Conclusions 

We  have  presented  a  new  system  for  defining  and  enforcing  fine-grain  access  control.  The  system  is  simple, 
relying  only  on  standard  techniques  from  the  types  literature,  yet  powerful  enough  to  express  many  non¬ 
trivial  access  control  policies  statically.  The  system  draws  its  power  from  two  key  features:  late  and  locally 
defined  access  control  policies  and  non-local  enforcement  of  the  policies.  We  make  the  former  possible 
through  late  binding  between  resources  and  key-pairs  identified  by  lexically  scoped  names.  To  make  the 
latter  possible,  we  use  subnaming. 

At  the  core,  our  use  of  subnaming  is  a  kind  of  local  must  alias  analysis.  This  technique  itself  appears  to 
be  applicable  to  a  variety  of  problems  in  addition  to  access  control. 
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X  G  Vars  £  G  Locations  k  G  KeyPairs  U  {bot,  top}  A  KeyPairs  U  {bot,  top} 


raw  values  r 
values  V 

expressions  e 


m  I  loc  {£)  I  Ikey  (fc)  |  gkey  (k)  \  {vi,V2,  ■  •  ■ ,  |  Xx:».e  |  A  •  .v  |  pack  u  as  • 

a;  I  fc  r  I  err 

V  I  (ei,  62,  •  •  • ,  e„)  I  e.z  I  Ci  62  |  ref  e  |  Ci  :  =  62  |  !  e  |  spawn  e  | 

6  [•]  I  pack  e  as  •  I  open  a;  =  ei  as  •  in  62  | 

limit  61, 62, ,  6„_i  in  e„  |  greuit  61  in  62  |  newkey<6  |  associate  ei  with  62  |  access  A  in  e 


Figure  5:  Target  language 


i?-contexts  R  ::=  [  ]  |  (. . . ,  Ui,  i?, . . .)  |  R.i  |  i?  e  |  u  i?  |  ref  R  \  R  :  =  e  \  v  :  =  R  \  R[»]  \  pack  i?  as  •  |  open  x  =  R  as  •  in 

limit  . . .  ,Vi,  R, . . .  in  6  I  grant  i?  in  e  |  newkey<i?  |  associate  R  with  e  \  associate  v  with  R 

E-contexts  E  ::=  [  ]  |  {. . .  ,Vi,  E, . . .)  \  E.i  \  E  e  \  v  E  \  ref  E  \  E  :  =  e  \  v  :  =  E  \  E  [•]  \  pack  i?  as  •  |  open  x  =  E  as  •  in 

limit  . . .  ,Vi,  E, . . .  in  6  I  grant  Fi  in  6  |  newkey<_E  |  associate  E  with  e  |  associate  v  with  E  \  E 

access  A  ±n  E 


Figure  6:  Evaluation  contexts 
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A  Type  Soundness 

We  sometimes  use  the  symbol  —  to  indicate  “don’t  care.” 

A.l  Dynamic  Semantics 

The  first  step  in  the  dynamic  semantics  is  to  translate  the  source  program  into  the  language  shown  in 
Figure  5.  The  translation  involves  type-erasure,  replacing  each  name  or  type  annotation  with  a  •.  We  erase 
names  and  types  so  that  we  do  not  need  to  worry  about  proper  alpha-renaming  of  names  during  reductions. 
Also  each  program  value  in  the  source  program  is  translated  into  a  program  value  in  of  the  target  program 
by  annotating  them  with  bot,  i.e.,  for  each  v  in  the  source,  bot  v.  Finally,  the  translation  replaces  each  Top 
with  bot  Ikey  (top). 

Let  6  be  the  translated  target  program.  Then  the  evaluation  proceeds  from  the  initial  state  (0,0,  (e)) 
followed  by  a  sequence  of  small-step  reductions  shown  in  Figure  7.  Each  state  is  of  the  form  {S,  K,  e)  where  S 
is  the  store  mapping  store  locations  to  values,  K  is  the  key-pair  manager  representing  immediate  sub-key-pair 
relation  between  key-pairs,  and  e  are  the  execution  threads. 

The  evaluation  contexts  E  and  R  are  shown  in  Figure  6.  The  only  difference  between  E  and  R  is  that  R 
lacks  access  A  in  R. 
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(S',  E[{vi,V2,  .  .  .  ,  w„)],  .  .  .))  - >  (S,  E[hot  {vi,V2,...,  . . .)) 

k  €  ClosexiA) 


[Tuple] 


(S,  K,{. . . ,  i?[access  A  in  R[{k  {. . .  ,Vi, . .  ■))■*]],  •  ■  •))  — >  (S,  K,{. . . ,  ii^[access  A  in  . . .)) 

k  €  ClosexiA) 


(S,  K,  ,  i?[access  A  in  R[{k  Ax:».e)  v]], . . .))  — >  (S,  K,  ,  £^[access  A  in  i?[e[f/x]]], . . .)) 

£  ^  dom{S) 


[Proj] 

[App] 


(S,i4:,  (...,£;[ref  v],...))  — >  {S  U  {£  v},  K,  ,  E[hQt  loc  (^)],...)) 

k  G  ClosexiA) 


[Ref] 


(S  U  — },  K,{. . . ,  i?[access  A  in  R[{k  loc  {£))  :=  u]], . .  .))  — >  (S  U  v},  K,{. . . ,  ii^[access  A  in  . . .)) 

k  G  ClosexiA) 


{S  Gi  {£  ^  v},K,  {. . . ,  i?[access  A  in  i?[ !  A:  loc  {£)]], . . .))  — >  (S  U  {A'  w},  iA,  (. . . ,  £^[access  A  in  . . .)) 

[Spawn] 


[D 


(S,  K,{. . . ,  ii^[spawn  e], . . .))  — >  (S,  K,{. . . ,  i?[bot  0], . . . ,  access  0  in  e)) 

k  G  ClosexiA) 


(S,  K,{. . . ,  ii^[access  A  in  R[{k  A  •  .v)  [•]]], . . .))  — >  (S,  K,{. . . ,  i?[access  A  in  . . .)) 

[Pack] 


[Inst] 


(S,  K,{. . . ,  i!^[pack  V  as  •], . . .))  - s-  (S,  K,{. . . ,  i?[bot  pack  v  as  •], . . .)) 

k  G  ClosexiA) 


(S,  K,  ,  i?[access  A  in  i?[open  x  =  {k  pack  v  as  •)  as  •  in  e]], . . .))  — >  (S,  K,  ,  _E[access  A  in  i?[e[f;/x]]], . . .)) 

{k[,k'^,...,k'JCCloseK{A) 


(S,  K,{. . . ,  ii^[access  A  in  i?[limit  Ikey  (fci),  Ikey  (^2),  ■  ■ .  ,k'„  Ikey  (A:„)  in  e]], . . .))  — > 

(S,  if,  (. . . ,  if[access  A  in  i?[access  ClosexiA)  n  CloseK{{ki,  fe,  ■  •  ■ ,  fc„})  in  e]], . . .)) 


[Limit] 


ki  G  Closex(A) 


(S,  if,  (. . . ,  i?[access  A  in  i?[grant  ki  gkey  (^2)  in  e]], . . .))  — >  (S,  if,  (. . . ,  if  [access  A  in  i?[access  A  U  {A:2}  in  e]], . . .) 
ki  G  ClosexiA)  ks  ^  dom{K)  U  {bot,top} 


(S,  if,  (. . . ,  if  [access  A  in  ii[newkey<fci  Ikey  (^2)]],  ■  •  •))  — > 

(S,  if  U  {ks  fc2},  (. . . ,  if  [access  A  in  i?[bot  pack  bob  (bot  Ikey  (fca),  bot  gkey  (fcs))  as  •]],.. .)) 


[Ne 


{^1,^2}  C  CloseK{A) 


(S,  if,  (. . . ,  if  [access  A  in  ii[associate  ki  r  with  k2  Ikey  (fcs)]], . . .))  — >  (S,  if,  (. . . ,  if  [access  A  in  i?[fc3  r]], . . .)) 

[InAccess] 


(S,  if ,  (. . . ,  if  [access  A  in  v] , . . .))  — s-  (S,  if ,(...,  if  [f] ,.. .)) 


Figure  7:  Small-step  reduction  rules 
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Thk:  p 


T  \-  k  m  :  p  ink, 

T  \-  ki  :  Pi  T  \-  k2  ■  P2 

r  h  fci  Ikey  (^2)  :  Pi  Ikey  (^2);  0 


(Int’ed) 


T  \-  k  :  p  V  ^  :  T 
T  k  loc  (£)  :  p  re/(r);  i 


(Loc) 


(LKey) 


r  h  fci  :  Pi 


T  \-  k2  '■  P2 


(GKey) 


T\-  k:  p 

For  1  <  i  <  n,  T  \-  Vi  :  Ti;{ 


T\-  k  {vi,V2,...,Vn)  ■■  p  (ti,T2,  . .  •  ,T„); 

r  I- fc  :  P3  r,  P1<P2  I"  V  :  t;0  r,pi<p2l"0 


(Tuple’ed) 


T\-  ki  gkey  (*2)  :  Pi  gkey  (^2);  0 

r  h  A:  :  p  r,  a;:Ti  h  e  :  r2;  F  r,a;:Til-o 
r  h  fc  Aa::*.e  :  p  (ti  — ^  T2);  0 


(Fun’ed) 


r  h  e  :  Pi  (Vp2<P3.t);L  F  h  pi  <  pa  , 

(Gen’ed)  - — - - - ^ - ,  1  .  ,  ,  r  . -  •) 


F  h  fc  A  •  .u  :  P3  (Vpi  <P2-t);  0  F  h  e  [•]  :  t[p4/p2];  A  U  {pi} 

F  h  fc  :  p4  F  h  V  :  r[p3/pi];  0  F  h  pa  <  p2 


F  h  A:  pack  v  as  •  :  p4  (3pi  <p2.r);  ( 


(Packed) 


F  h  e  :  r[p3/pi];  L  F  h  pa  <  p2 


(Pack  •) 


F  h  Cl  :  Pi  (3p2<p3.ri);  Li  F,  p2  <P3,  a;:Ti  F  62  :  r2;  A2 

F  h  r2  F  h  L2  r,p2<p3,a;:Ti  F  o 


F  F  pack  e  as  •  :  _L  (3pi  <p2.r);  L  F  F  open  a;  =  ei  as  •  in  62  :  r2;  Li  U  L2  U  {pi} 

FFe:T;L  FFL<{p|FFA::pfor  some  k  G  A} 


(Open  •) 


k:p  G  F 
F  F  A:  :  p 


(KeyPair  k) 


F  F  top  :  T 
F  F  p  F  Fo 


F  F  access  A  in  e  :  t 

(KeyPair  top) 


(InAccess) 


F,  A::p  F  o 


(Env  k) 


F  F  bot  :  _L 
FFr  FFo 


T,£:t  F  o 


(KeyPair  bot) 


(Env  £) 


£:t  G  F 
FFA:  T 


(Location  £) 


Figure  8:  Type  checking  rules:  additional  rules  for  the  target  language 


CIosck  is  a  function  such  that  k  G  ClosexiA)  iff  A;  is  a  sub-key-pair  of  some  key-pair  in  A  in  the  key-pair 
relation  K.  More  concretely,  we  define  the  reflexive,  transitive  closure  of  K  lifted  with  bot  as 

=  Unccv  U  {bot  I— >  A;  I  A:  G  dom{K)  U  {top}}) 

U{A:  1-^-  A:  I  A;  G  dom{K)  U  {bot,  top}} 


where 

R{K)  =  K  \J  {ki  ^  k2  \  ki  ^  k^.  &  K  and 

ks  1-^  k2  &  K  for  some  A:3} 

Then  CIosck  can  be  defined  as 

ClosexiA)  =  {ki  I  A:i  I— >  A;2  G  for  some  k2  G  A} 

If  the  state  {S,  K,{. . .  ,e, . . .))  cannot  be  reduced  by  the  rules  in  Figure  7  but  e  is  not  a  value,  then  e 
immediately  reduces  to  a  special  constant  err,  i.e. 

(S',  K,  - >  (S,  err, . . .)) 


A. 2  Type  Soundness 

The  static  semantics  for  the  target  language  is  the  type  checking  rules  from  Section  3.1  plus  the  additional 
rules  in  Figure  8.  Each  type  environment  is  now  a  sequence  of  variable-to-type  bindings,  names  annotated 
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with  a  supername,  location-to-type  bindings,  and  key-pair-to-name  bindings. 

r  ::=  0  I  r, a;:T  |  T,pi<p2  \  I'-t  \  k:p 

Note  that  err  has  no  type.  The  following  theorem  connects  source  programs  to  target  programs. 

Theorem  2  Let  ei  be  an  expression  in  the  source  language  and  62  he  the  corresponding  translated  expression. 
Then  ifT\-ei  :  t;L  then  T  \-  62  ■  t;  L. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

In  the  rest  of  the  paper,  we  always  refer  to  expressions  in  the  target  language  unless  specified  otherwise. 
We  re-state  the  definition  of  well-typed  program  state. 

Definition  2  T  h  (S',  K,  (ei,  62, ... ,  e„))  (read  “the  program  state  (S,  K,  (ei,  62, ... ,  e„))  is  well-typed  under 
T”)  tff 

(1)  Tho. 

(2)  For  each  1  <  t  <  n,  T  h  ;  0. 

(3)  I  €  dom{S)  iff  £  G  dom{T). 

(4)  k  €  dom{K)  iff  k  G  dom{T). 

(5)  X  ^  dom{T). 

(6)  If  T  \-  £  :  T  and  S {£)  =  V  then  T  \-  V  :  t;  — . 

(7)  Suppose  T  \-  ki  :  Pi  and  T  \-  k2  ■  P2-  Then  T  \-  pi  <  p2  (iff  fci  >  ^2  G  K±- 
Lemma  1  //Tho  and  T  h  e  :  r;  L  then  T  h  r  and  T  \-  L. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

Lemma  2  (Substitution)  (1)  IfT,x:Ti  ho,  T,  a;:Ti  h  e  :  T2;  L,  and  T  h  u  :  n;  0,  then  T  h  e[w/a;]  :  T2;L. 

(2)  //r,pi<p2  ho,  V,pi<p2  h  e  :  r;L,  and  T  h  pa  <  p2,  then  The:  t[p3/ pi];  L[p3/ pi], 

(3)  //r,pi<p2  h  o,  r,pi<p2  h  n  <  T2,  and  r  h  P3  <  P2,  then  T  h  ri[p3/pi]  <  T2[p3/pi]- 

(4)  //r,pi  <  P2,x:ti  h  o,  r,pi  <  P2,a;  :  Ti  h  e  :  T2;L,  and  T  h  pa  <  p2,  then  r,a:  :  Ti[p3/pi]  h  e  : 

T2[p3/pi];  L[p3/pi]. 

Proof:  By  induction  on  the  type  checking  derivation.  □ 

Lemma  3  Suppose  Ti  h  o  and  Ti  h  e  :  r;  L.  Then  for  any  r2  3  Ti  such  that  r2  h  o,  r2  h  e  :  t;  L. 

Proof:  The  only  non-trivial  case  is  when  r2  contains  more  instances  of  name  bindings,  i.e.,  p<— ’s,  than 
Ti,  since  type  environment  well-formedness  conditions  may  fail  with  more  names.  But  it  is  easy  to  see  that 
whenever  a  new  name  is  introduced  in  the  environment,  we  may  choose  a  name  that  has  not  appeared  in  the 
environment  (see  (Gen’ed)  and  (Open  •)).  By  Lemma  1,  the  choices  do  not  affect  the  conclusions.  Hence 
the  lemma  follows.  □ 

Lemma  4  (Replacement)  Suppose  Ti  h  o  and  Ti  h  E[ei\  :  r;  L.  Then  there  is  a  sub-derivation  Ti  h  ei  : 
Ti;  Li  for  some  Furthermore,  for  any  62  and  r2  O  Ti  such  that  r2  h  o  and  r2  h  62  :  ri;  Li,  we  have 

r2  h  if  [62]  :  r;  L. 

Proof:  This  follows  from  the  usual  replacement  argument  and  Lemma  3.  □ 

Lemma  5  Suppose  T  h  R[e]  :  r;  L.  Let  T  h  e  :  ti;  Li  he  a  sub -derivation.  Then  T  \-  Li  <  L. 
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Proof:  By  induction  on  the  type  checking  derivation. 
Lemma  6  If  T  h  v  :  t;  L  then  F  h  w  :  r;  0. 


□ 


Proof:  By  induction  on  the  type  checking  derivation.  □ 

We  are  now  prepared  prove  our  main  theorem,  re-stated  here. 

Theorem  3  (Subject  Reduction)  IfT  h  {S,K,e)  and  {S,K,e)  — >  (S' ,  K' ,(f),  then  there  is  F'  such  that 
T'  h 

Proof:  Firstly,  we  show  that  for  each  G  e,  if  is  not  a  value  then  (S',  K,  e)  is  of  the  form  matching 
the  left  hand  side  of  — >  in  one  of  the  reduction  rules  from  Figure  7  with  as  the  evaluating  thread.  To 
see  this,  first  note  that  for  [Proj],  [App],  [Ref],  [Assign],  [Deref],  [Open],  [Limit],  [Grant],  [NewKey],  and 
[Associate],  the  redex  indeed  does  appear  in  some  context  of  the  form  if  [access  A  in  R[  ]]  since  otherwise 
it  must  appear  in  some  context  of  the  form  R[  ]  but  then  by  Lemma  5  F  1/  ;  0.  Secondly,  for  [Assign] 

(ref.  [Deref]),  the  location  assigned  (ref.  dereferenced)  must  be  in  the  store  because  otherwise  it  violates 
Definition  2  (3). 

Therefore  it  suffices  to  show  the  statement  in  the  theorem  holds  for  each  forms  matching  {S,  K,  e) . 


[Tuple]  Suppose 

F  h  (S',  AT,  (. . . ,  E[{vi,V2,  . . . ,  Vn)],  ■ . .)) 

So  we  have  F  h  E[{vi,V2,  ■  ■  ■  ,u„)]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must  be  a  sub¬ 
derivation  with  (Tuple)  as  the  last  rule. 

For  1  <  i  <  n,  T  \-  Vi  :  Til  Li 
Fh  {vi,V2,...,Vn)  :  -L  (Ti,r2,...,r„);Ui<*<„Ai 

We  have 

(S,  AT,  (. . . ,  E[{vi,V2,  . . . ,  Vn)],  ■■■})  - > 

(S,  A[bot  {vi,V2,...,  Vn)],  ■ . .)) 

Let  F'  =  F.  We  have  by  (Tuple’ed) 

F'  h  hot  :  _L 

For  1  <  i  <  n,  T'  \-  Vi  :  Ti]^ 

F'  h  bot  {vi,V2, . . . ,  v„)  :  _L  {ti,T2,  . .  ■  ,r„);0 

Then  by  Lemma  1  and  (Subsumption), 

F' F  bot  (vi,W2, . . .  : -L  (ri,T2, . . .  ,T„);  |J  Li 

l<i<n 

Hence  by  Lemma  4,  it  follows  that 

F'  h  (S,  AT,  (...,A;[bot  {vi,V2,...,Vn)],...)) 


[Proj]  Suppose 

F  h  (S,  AT,  (. . . , if[access  A  in  R[{k  {. . .  ,Vi, . .  ■)).*]],  • .  •)) 

So  we  have  F  F  A[access  A  in  R[{k  {. . .  ,Vi, . .  .)).i]]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there 
must  be  a  sub-derivation  with  (Proj)  as  the  last  rule. 

T  \-  k  {. . .  ,v^,. . .)  :  p  {ti,T2,.  ■  .,t„);L 
F  F  (fc  (. . . ,  Vj, . .  .)).i  :  Ti;  LU  {p} 

We  first  show  that 

(S,  AT,  (. . . ,  if  [access  A  in  R[{k  {. . .  ,Vi, . .  ■))•*]], . . .)) 

— >  (S,  AT,  (. . . ,  A[access  A  in  i?[ti]], . . .)) 
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It  suffices  to  show  that  k  G  Closex(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {p\  <  {/9  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

TGk-.  p'  TG  p'  <p 

So  by  Definition  2  (7),  k  G  ClosexiA). 

Now  let  r'  =  r.  We  next  show  that 


r'  h  (S',  K,{. . . ,  if[access  A  in  . . .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  premise  must  end  with 
(Tuple’ed)  followed  by  zero  or  more  (Subsumption) ’s.  So 

T'Gv,:T';iD  T' G  t' <  t,  T  h  0  <  L  U  {p} 

So  by  Lemma  1  and  (Subsumption) 

r'  h  Wj  :  Ti]  L  U  {p} 


So  by  Lemma  4  it  follows  that. 


r'  h  (S,  K,{. . . ,  if[access  A  in  i?[vi]], . . .)) 


[App]  Suppose 

r  h  (S,  AT,  (. . . ,  if[access  A  in  R[{k  Xx:u.e)  f]], . . .)) 

So  we  have  L  h  if  [access  A  in  R[{k  Xxiu.e)  v]]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must 
be  a  sub-derivation  with  (App)  as  the  last  rule. 

r  h  A:  Xx:».e  :  p  (ji  T2);  L2  L  h  v  :  ri;  L3 
r  h  fc  Xx\».e  V  :  T2]  Li  U  L2  U  L3  U  {p} 

We  first  show  that 

(S',  K,{. . . ,  if  [access  A  in  R[{k  Xx:».e)  wj], .  • .))  — > 

(S,  K,{. . . ,  if[access  A  in  i?[e[w/a:[[], . . .)) 

It  suffices  to  show  that  k  G  CloseK{A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {p}  <  {p  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

rhfc:p'  rhp'<p 

So  by  Definition  2  (7),  k  G  CloseK{A). 

Now  let  r'  =  r.  We  next  show  that 

r'  G  (S,  K,{. . . ,  if[access  A  in  ^[e)?;/^]]], . . .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  first  premise  must  end  with 
(Fun’ed)  followed  by  zero  or  more  (Subsumption) ’s.  So 

T' ,x:t[  G  e  :  T2;  L[  r',a::r(l-o 

r'  h  n  <  L'  h 

T'  G  L[<Li  r'  h  0  <  L2 

So  by  (Subsumption), 

r'  h  -y  :  t(;  L3 

and  by  Lemma  2  (1),  Lemma  1,  and  (Subsumption), 

r'  h  e[v/x\  :  T2;  Li  U  L2  U  L3 

So  by  Lemma  4  it  follows  that 

r'  h  (S',  K,{. . . ,  if  [access  A  in  i?[e[y/a;]][, . . .)) 
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[Ref]  Suppose 


rh  (S',X,  (...,£;[ref  u],...)) 

So  we  have  T  h  i?[ref  v]  :  —  ;0.  By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation 
with  (Ref)  as  the  last  rule. 

T  \-  V  :  t;  L 

r  h  ref  V  :  _L  ref{T);  L 

We  have 

{S,K,{...,E[rei  u],...))  — > 

(S'  U  {f  u},  K,{. . . ,  i?[bot  loc  {£)], . . .)) 

for  £  ^  dom{S).  Let  V  =  T,£:t.  We  have  by  (Loc) 

r'  h  bot  :  _L  V  \-  £  :  T 
r'  h  bot  loc  {£)  :  _L  re/(T);  0 

Then  by  Lemma  1  and  (Subsumption), 

h  bot  loc  {£)  :  _L  re/(T);  L 

Now,  we  have  T'  \-  £  :  t,  (SU  {£  t})(f)  =  v,  and  L  h  u  :  r;  — .  Hence  by  Lemma  3  and  Lemma  4,  it  follows 

that 

r'  h  (S  U  {£  u},  K,{. . . ,  i?[bot  loc  (£)], . . .)) 

[Assign]  Suppose 

r  h  (S  U  {£  — },  K,  {. . . ,  if  [access  A  in  R[{k  loc  {£))  :  =  w]], . . .)) 

So  we  have  L  h  if  [access  A  in  R[{k  loc  (i))  :  =  v]]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there 
must  be  a  sub-derivation  with  (Assign)  as  the  last  rule. 

r  h  fc  loc  {£)  :  p  ref{T);  Li  L  h  u  :  r;  L2 
r  h  (fc  loc  {£))  :=  u  :  r;  Li  U  L2  U  {p} 

We  first  show  that 

(S  U  {£  1-^-  — },  K,{. . . ,  if[access  A  in  R[{k  loc  {£))  ;=  u]], . . .)) 

— >  (S  U  {£  1-^-  u},  K,{. . . ,  if  [access  A  in  ii[v]], . . .)) 

It  suffices  to  show  that  k  G  CloseK(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {p}  <  {p  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

rhfc:p'  rhp'<p 

So  by  Definition  2  (7),  k  G  ClosexiA). 

Now  let  r'  =  r.  We  next  show  that 

r'  h  (S'  U  {£  1-^-  u},  K,{. . . ,  if  [access  A  in  ii[v]], . . .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  first  premise  must  end  with 
(Loc)  followed  by  zero  or  more  (Subsumption) ’s.  So 

T'G£:t 

(Subtyping  is  invariant  under  pointer  types.)  Hence  Definition  2  (6)  is  satisfied.  Also  by  Lemma  1  and 
(Subsumption) 

r  h  u  :  r;  Li  U  L2  U  {p} 

Hence  by  Lemma  4,  it  follows  that 

r'  h  (S  U  {£  1-^-  u},  K,{. . . ,  if  [access  A  in  ii[w]], . . .)) 
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[Deref]  Suppose 


r  h  (S'  U  {£  u},  K,{. . . ,  £^[access  ^  in  i?[!  k  loc  (£)]], . . .)) 

So  we  have  T  h  i?[access  ^  in  i?[!  fc  loc  (£)]]  :  — ;0.  By  inspection  of  the  type  checking  rules,  there  must 
be  a  sub-derivation  with  (Deref)  as  the  last  rule. 

r  h  fc  loc  {£)  :  p  refir);  L 
r  h  !  fc  loc  {£)  :  t;  LU  {p} 

We  first  show  that 

(S  U  {t'  v},  K,{. . . ,  if  [access  A  in  i?[ !  k  loc  (£)]], .  • .)) 

— >  (S  U  {£  v},  K,{. . . ,  if[access  A  in  i?[u]], . . .)) 

It  suffices  to  show  that  k  G  CloseK(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {p}  <  {p  \T  \-  k  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

TGk:  p'  TG  p'  <p 

So  by  Definition  2  (7),  k  G  CloseK{A). 

Now  let  r'  =  r.  We  next  show  that 

r'  h  (S  U  {£  u},  K,{. . . ,  if  [access  A  in  i?[v]], . . .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  premise  must  end  with  (Loc) 
followed  by  zero  or  more  (Subsumption) ’s.  So 

r'Gi-.T 


(Subtyping  is  invariant  under  pointer  types.)  Hence  by  Definition  2  (6)  and  Lemma  6,  it  must  be  the  case 
that 

r  h  u  :  r;  0 


So  by  Lemma  1  and  (Subsumption) 


r  h  u  :  r;  L  U  {p} 


Hence  by  Lemma  4,  it  follows  that 


r'  h  (S'  U  {£  1-^-  u},  K,{. . . ,  if  [access  A  in  i?[w]], . . .)) 


[Spawn]  Suppose 

r  h  {S,  K,  ,  if  [spawn  e], . . .)) 

So  we  have  L  h  if  [spawn  e]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation 
with  (Spawn)  as  the  last  rule. 

r  h  e  :  r;  0 

r  h  spawn  e  :  _L  int;  0 

We  have 

(S,A:,  (...,A[spawne],...))  — > 

(S,  K,{. . . ,  if  [bot  0], . . . ,  access  0  in  e)) 

Let  r'  =  r.  We  have  by  (Int’ed) 

r'  h  bot  :  _L 
r'  h  bot  0  :  _L  int]  0 

Also  by  (InAccess), 

r'  h  e  :  t;  0  L'  h  0  <  0 
r'  h  access  0  in  e  :  r;  0 

Hence  by  Lemma  4,  it  follows  that 

h  (S,  K,  ,  if  [bot  0], . . . ,  access  0  in  e)) 
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[Inst]  Suppose 


r  h  {S,  K,  ,  i?[access  A  in  R[{k  A  •  .v)  [•]]], . . .)) 

So  we  have  F  h  i?[access  A  in  R[{k  A  •  .v)  [•]]]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must 
be  a  sub-derivation  with  (Inst  •)  as  the  last  rule. 

T  \-  k  A  •  .V  :  Pi  (Vp2  <P3-t);  L  T  \-  p4  <  ps 

r  h  (fc  A  •  .u)  [•]  :  t[p4/p2];L  U  {pi} 

We  first  show  that 

{S,  K,{. . . ,  if  [access  A  in  R[{k  A  •  .v)  [•]]], . . .)) 

— >  (S',  K,  {. . . ,  if  [access  A  in  i?[u]], . .  •)) 

It  suffices  to  show  that  k  G  CloseK(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {p}  <  {p  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

rhfc:p'  rhp'<p 

So  by  Definition  2  (7),  k  G  ClosexiA). 

Now  let  r'  =  r.  We  next  show  that 

r'  h  (S,  K,  {. . . ,  if  [access  A  in  i?[w]], .  • .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  first  premise  must  end  with 
(Gen’ed)  followed  by  zero  or  more  (Subsumption) ’s.  So 

r',p2<P3  h  V  :  r';  0  r',p2<P3l-o 

r'  b  P3  <  Pg  r'  h  r'  <  r 
F'  h  0  <  A 

So  we  have 

F'  h  P4  <  P3 

and  by  Lemma  2  (2),  Lemma  1,  and  (Subsumption), 

F'  h  V  :  r[p4/p2];  AU  {pi} 

So  by  Lemma  4  it  follows  that 

F'  h  (S',  K,  {. . . ,  A[access  A  in  i?[w]], .  • .)) 


[Pack]  Suppose 

F  h  (S,  iF,  (. . . ,  A[pack  v  as  •], . . .)) 

So  we  have  F  h  A[pack  u  as  •]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation 
with  (Pack  •)  as  the  last  rule. 

F  h  u  :  r[p3/pi];  A  F  h  pg  <  p2 
F  h  pack  u  as  •  :  A  (3pi  <P2.t);  A 

We  have 

(S,  K,{. . . ,  A[pack  u  as  •], . . .))  — > 

(S,  K,  ,  A[bot  pack  v  as  •], . . .)) 


Let  F'  =  F.  We  have  by  (Packed) 


F' F  bot  :  A  F' h  u  :  r[p3/pi];  0  F' b  pa  <  P2 
F'  b  bot  pack  w  as  •  :  A  (3pi  <P2.t);  0 


Then  by  Lemma  1  and  (Subsumption), 


F^  b  bot  pack  u  as  •  :  A  (3pi  <p2.r);  A 


Hence  by  Lemma  4,  it  follows  that 

F^  b  (S,  K,  ,  A[bot  pack  v  as  •], . . .)) 
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[Open]  Suppose 


r  h  (S,  K,  ,  i?[access  A  in  i?[ 

open  X  =  {k  pack  v  as  •)  as  •  in  ej], . . .)) 

So  we  have 

r  h  i?[access  A  in  i?[open  x  =  (k  pack  v  as  •)  as  •  in  e]]  :  — ;  0 
By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation  with  (Open  •)  as  the  last  rule. 

r  h  (fc  pack  V  as  •)  :  pi  {3p2<P3-Ti)]  Li 
T,P2<P3,x:ti  h  e  :  T2;L2 

T  \-  T2 _ r  h  L2 _ r,  p2<P3,a::Ti  ho 

r  h  open  X  =  (k  pack  ri  as  •)  as  •  in  e  :  T2;  Li  U  L2  U  {pi} 

We  first  show  that 

(S',  K,  ,  i?[access  A  in  R[ 

open  X  =  {k  pack  v  as  •)  as  •  in  ej], . . .)) 

— >  (S,  K,  {. . . ,  if  [access  A  in  i?[e[r;/a;]]], . . .)) 

It  suffices  to  show  that  k  G  CloseK(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {pi\  <  {p  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'^  such  that 

r  h  fc  :  p'l  r  h  pi  <  Pi 

So  by  Definition  2  (7),  k  G  CloseK{A). 

Now  let  r'  =  r.  We  next  show  that 


r'  h  (S,  K,{. . . ,  if[access  A  in  i?[e[u/a:]]], . . .)) 

By  inspection  of  the  type  checking  rules,  we  see  that  the  sub-derivation  of  the  first  premise  must  end  with 
(Packed)  followed  by  zero  or  more  (Subsumption) ’s.  That  is,  for  some  p4 

r'  h  :  t[[p4/p2];0 
r'  h  P4  <  p'3  r'  h  p'3  <  p3 

^',P2<P3  \-t[  <Ti 

So  we  have  by  Lemma  2  (3) 

r'  I-  [P4/P2]  <  Ti  [P4/P2] 

SO 

r'  h  :  Ti[p4/p2];0 

Furthermore,  because  F'  h  T2,  F'  h  L2  and  F'  h  p4  <  p2,  we  have  by  Lemma  2  (4) 

F',a;:Ti[p4/p2]  b  e  :  T2;L2 


Hence  by  Lemma  2  (1) 

Finally  by  Lemma  4  it  follows  that 


F'  h  e[v/x]  :  T2;  L2 


F'  h  {S,  K,{. . . ,  if  [access  A  in  i?[e[u/a;]]], . . .)) 
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[Limit]  Suppose 


r  h  (S',  K,  ,  £^[access  A  in  i?[ 

limit  k[  Ikey  (fci),  Ikey  (fc„)  in  ej], . . .)) 

So  we  have 

r  h  _E[access  A  ini?[ 

limit  k'l  Ikey  (fci), . . .  ,k'^  Ikey  (fc„)  in  ej]  :  — ;  0 

By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation  with  (Limit)  as  the  last  rule. 

For  1  <  i  <  n,  r  h  A:'  Ikey  (ki)  :  p[  Ikey  (pi);  Li 

r  F  e  :  r;  L _ F  h  £  <  {pi,p2,  ■  ■  ■ ,  Pn} 

F  h  limit  k'l  Ikey  (ki),  ■  ■  ■  ,k'^  Ikey  (fc„)  in  e  : 

r;  L  U  Ui<i<n-i(^i  F  {p^}) 

Let  B  =  ClosexiA)  n  CloseK{{ki,k2,  ■  ■  ■ ,  fc„}).  We  first  show  that 

(S,  K,  ,  i?[access  A  in  R[ 
limit  k'l  Ikey  (/ci),  ...,k'^  Ikey  (fc„)  in  ej], . . .))  — > 

(S,  K,  ,  i?[access  A  in  i?[access  B  in  ej], . . .)) 

It  suffices  to  show  that  for  1  <  i  <  n,  fc'  G  CloseK{A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case 
that 

r  F  Ip'}  <  {p  I  F  F  A:  :  p  for  some  k  €  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p"  such  that 

F  F  fc'  :  p"  F  F  p'l  <  p' 


So  by  Definition  2  (7),  A:'  G  CloseK{A). 

Now  let  F'  =  F.  We  next  show  that 

F^  F  (S,  K,  ,  if[access  A  in  i?[access  B  in  ej], . . .)) 


Firstly,  by  Lemma  5 


F'  F  L  <  {p  I  F  F  A:  :  p  for  some  A:  G  A} 

Hence  by  F'  F  £  <  {pi,  p2,  ■  •  ■ ,  Pn}  and  Definition  2  (7),  it  follows  that 

F'  F  £  <  {p  I  F  F  fc  :  p  for  some  k  G  B} 

(Since  subtyping  is  invariant  for  limit  key  types.)  Then  by  Lemma  1  and  (Subsumption), 


F^  F  access  H  in  e  :  t;  £  U  £i  U  {p(} 

l<i<n-l 


Hence  by  Lemma  4,  it  follows  that 

F^  F  (S',  K,  ,  £[access  A  in  i?[access  B  in  ej], . . .)) 


[Grant]  Suppose 


F  F  (S,  AT,  (. . . ,  £[access  A  in  i?[grant  ki  gkey  (^2)  in  e]], . . .)) 

So  we  have  F  F  £[access  A  in  i?[grant  ki  gkey  (^2)  in  e]]  :  — ;  0.  By  inspection  of  the  type  checking  rules, 
there  must  be  a  sub-derivation  with  (Grant)  as  the  last  rule. 

F  F  A:i  gkey  (^2)  :  pi  gkey  (P2);  £1 

_ F  F  e  :  r;£2  U  {P2} _ 

F  F  grant  A:i  gkey  (^2)  in  e  :  t;  £1  U  £2  U  {pi} 


30 


We  first  show  that 

(S',  K,{. . . ,  i?[access  A  in  i?[grant  ki  gkey  (^2)  in  e]], . . .))  — > 

(S,  K,  ,  i?[access  A  in  i?[access  A  U  {k2}  in  e]], . . .)) 

It  suffices  to  show  that  ki  G  Closex(A).  By  Lemma  5  and  (InAccess),  it  must  be  the  case  that 

r  h  {pi}  <  {p  I  r  h  fc  :  p  for  some  k  €  Aj 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

r  h  ki  :  p'  r  h  p'  <  Pi 

So  by  Definition  2  (7),  fci  G  CloseK(A). 

Now  let  r'  =  r'.  We  next  show  that 

h  (S,  K,  (. . . ,  if  [access  A  in  i?[access  A  U  {^2}  in  e]], . . .)) 

By  Lemma  5 

r'  h  L  <  {p  I  r  h  /c  :  p  for  some  k  G  A} 

Therefore  by  Definition  2  (7),  it  follows  that 

r'  h  L  U  {P2}  <  {p  I  r  h  fc  :  p  for  some  k  G  ALI  {^2}} 

(Since  subtyping  is  invariant  for  grant  key  types.)  Then  by  Lemma  1  and  (Subsumption), 

h  access  A  U  {^2}  in  e  :  r;  Li  U  L2  U  {P2} 

Hence  by  Lemma  4,  it  follows  that 

h  (S',  K,  {. . . ,  if  [access  A  in  i?[access  A  U  {^2}  in  e]], . . .)) 


[NewKey]  Suppose 


r  h  (S,  K,  {. . . ,  if[access  A  in  i?[newkey<fci  Ikey  (^2)]])  •  ■  •)) 

So  we  have  T  h  if[access  A  in  i?[newkey<fci  Ikey  (^2)]]  :  By  inspection  of  the  type  checking  rules, 

there  must  be  a  sub-derivation  with  (NewKey)  as  the  last  rule. 

_ r  h  fci  Ikey  (fc2)  :  Pi  Ikey  (P2);  L _ 

r  h  newkey<fci  Ikey  (k^)  '■ 

T  (3p3  <  P2-L  (T  Ikey  (ps),  T  gkey  (pa)));  L  U  {pi} 


We  first  show  that 


(S,  K,  ,  if[access  A  in  i?[newkey<fci  Ikey  (^2)]],  • .  •))  — > 

(S,  K  U  {ks  fe})  (•  •  • ,  if  [access  A  in  R[ 
bot  pack  bot  (bot  Ikey  (fcs),  bot  gkey  (fca))  as  •]],.. .)) 

for  some  ks  ^  dom{K)  U  {bot,  top}.  It  suffices  to  show  that  ki  G  CloseK(A).  By  Lemma  5  and  (InAccess), 
it  must  be  the  case  that 

r  h  {pi}  <  Ip  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

r  h  fci  :  p'  r  h  p'  <  Pi 


So  by  Definition  2  (7),  fci  G  CloseK{A). 
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Pick  p3  ^  dom{T)  U  {_L,T}.  Let  P'  =  T,p3<p2,k:p3.  We  next  show  that 

r'  h  (S',  iL  U  {ks  fe},  (•  ■  • ,  iii[access  A  in  R[ 

bot  pack  bot  (bot  Ikey  (fcs),  bot  gkey  (fcs))  as  •]],.. .)) 

By  (Packed)  and  (Tuple’ed),  we  have 

r'  h  bot  pack  bot  (bot  Ikey  (ks),  bot  gkey  (/cs))  as  •  : 

-L  (3p3  <  P2-L  (-L  Ikey  (^2),  -L  gkey  (^2)));  0 

Hence  by  Lemma  1  and  (Subsumption), 

r'  h  bot  pack  bot  (bot  Ikey  (/cs),  bot  gkey  (^3))  as  •  : 

_L  {3p3  <  p2.±  (-L  Ikey  (^2),  -L  gkey  (^2)));  L  U  {pi} 

Also,  it  is  easy  to  see  that  Definition  2  (4)  and  (7)  is  satisfied.  Hence 

r'  h  (S,  AT  U  {k3  fe},  (•  ■  • ,  ^[access  A  in  R[ 

bot  pack  bot  (bot  Ikey  (^3),  bot  gkey  (fcs))  as  •]],.. .)) 

[Associate]  Suppose 

r  h  (S,  K,  ,  ^[access  A  in  i?[ 

associate  ki  r  with  k2  Ikey  (fcs)]], . . .)) 

So  we  have 

r  h  ^[access  A  in  i?[associate  ki  r  with  k2  Ikey  (^3)]]  :  — ;  0 
By  inspection  of  the  type  checking  rules,  there  must  be  a  sub-derivation  with  (Associate)  as  the  last  rule. 

r  h  fei  r  :  Pi  g;  £1 _ P  h  fc2  Ikey  {k3)  :  p2  Ikey  (P3);  £2 

r  h  associate  ki  r  with  ^2  Ikey  (^3)  :  p3  a;  £1  U  £2  U  {pi,  P2} 

We  first  show  that 

(S',  £!,(...,  £[access  A  in  i?[ 

associate  ki  r  with  ^2  Ikey  (^3)]], . . .))  — > 

(S,  K,{. . . ,  £[access  A  in  i?[fc3  r]], . . .)) 

It  suffices  to  show  that  ki  G  CloseK{A)  and  k2  G  CloseK{A).  By  Lemma  5  and  (InAccess),  it  must  be  the 
case  that 

r  h  {pi}  <  {p  I  r  h  fc  :  p  for  some  k  G  A} 

By  inspection  of  the  type  checking  rules,  we  see  that  there  must  be  p'  such  that 

r  h  /ci  :  p'  r  h  p'  <  Pi 

So  by  Definition  2  (7),  fci  G  CloseK{A).  The  case  for  k2  is  analogous. 

Now  let  r'  =  r.  We  next  show  that 

r'  h  (S,  K,  {. . . ,  £[access  A  in  R[k3  rj], . . .)) 

The  cases  split  between  (Int’ed),  (Loc),  (Lkey),  (Gkey),  (Tuple’ed),  (Fun’ed),  (Gen’ed),  and  (Packed)  de¬ 
pending  on  a,  but  in  each  case  we  have 

r'  h  ^3  r  :  p3  g;  0 

(Since  subtyping  is  invariant  for  limit  key  types.)  Then  by  Lemma  1  and  (Subsumption), 

r'  h  fc3  r  :  p3  g;  £1  U  £2  U  {pi,  P2} 


Hence  by  Lemma  4,  it  follows  that 

r'  h  (S',  K,  {. . . ,  £[access  A  in  R[k3  rj], . . .)) 
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[InAccess]  Suppose 


r  h  (S',  K,  ,  i?[access  A  in  u], . . .)) 

So  we  have  T  h  _E[access  A  in  v]  :  — ;  0.  By  inspection  of  the  type  checking  rules,  there  must  be  a 
sub-derivation  with  (InAccess)  as  the  last  rule. 

T  \-  V  :  t;  L  T  \-  L  <  {p  \  T  \-  k  :  p  for  some  k  G  A} 
r  h  access  A  in  v  :  r;  0 

We  have 

(S,  K,{. . . ,  if  [access  A  in  u], . . .))  — >  (S,  K,{. . . ,  E[v], . . .)) 

Let  r'  =  r.  Then  by  Lemma  6, 

r  h  u  :  r;  0 

Hence  by  Lemma  4,  it  follows  that 

r'h(s,A,(...,ifH,...)) 

This  concludes  the  proof  of  Theorem  3.  □ 

Let  e  be  a  source  program.  We  say  that  e  gets  stuck  if  it  cannot  be  translated  to  the  target  language  or 
if  its  evaluation  reaches  a  state  of  the  form  (S,  A,  (. . . ,  err, ...)). 

Corollary  1  (Type  Soundness)  If  the  program  e  is  well-typed  then  it  does  not  get  stuck. 

Proof:  Recall  that  each  source  program  e  is  well-typed  iff  0  h  e  :  — ;  0.  The  corollary  follows  from  Theorem  2 
and  Theorem  3  since  the  initial  state  (0,  0,  (e))  is  well-typed  under  the  type  environment  0.  □  The 

corollary  implies  that  a  well-typed  program  does  not  violate  its  access  control  policy. 
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